sharkbot

Before enlightenment, chop wood and carry water.

After enlightenment, chop wood and carry water.

Buddhism (as I imperfectly understand it) is not about getting rid of materialistic attachments. It’s realizing materialistic attachments are the source of suffering.

The world remains. What you do within it is up to you.

The S&P500 index is about 20% off the highs. The NASDAQ index is ~35% off. And some big tech names are down 70% or more (Teledoc, Zoom, …).

The stock market is doing alright. Some investors are getting destroyed. And some new investors are receiving a very useful, very painful lesson.

(Full disclosure: I’m mainly a buy and hold index investor)

The constructivist in me thinks we could define it inductively :)

By coincidence, Teenage Engineering is on the front page at the same time as this article. I’ve enjoyed playing and creating music on their pocket operator devices, specifically the PO-20 chip tune one. The sound palette is a bit limited, but the chord opens up a lot of opportunity for creativity, especially with a little bit of music theory to help.

You’ve hit upon one of the key insights in category theory. It’s been awhile, let me see if I can remember enough to describe the sketch…

“Equality” is a tricky concept, and various branches of mathematics have slightly different ideas (or axioms) of equality. Simple arithmetic is based upon strict equality: two things are equal if and only if a sequence of logical steps are followed precisely and the final answer matches exactly. Other branches have looser (or just different) versions of equality: set theory may use a relation to induce an equivalence relation, topology may see things as equal based on structure preserving transformations, computer science has notions of program equivalence based on identical outputs given identical inputs, etc.

Category theory is an attempt to identify and unify various similar concepts across mathematical branches, including “equality”. Category theorists are limited to talking about objects (which are opaque), and arrows between those objects. Using those (incredibly) abstract tools, how does one define “equality”? The answer is, one can’t, so what are the closest things possible that capture “equality”, and can be specialized back into more traditional notions as needed.

Part of the confusion is that category theory is described from the “arrows and objects” perspective, when the really interesting stuff happens two layers higher (natural transformations and above). And another part of the confusion is that many mathematicians see category theory as needless nonsense :)

Part of what attracted me to technology, computers, programming, etc is the ability and freedom to tinker and experiment with ideas.

If I’m building something professionally, then difficulty in building, reading and maintaining is a problem.

If I’m building something to learn or to be creative, I don’t worry about how difficult it is to build or read or maintain: my aim is different, and therefore so are my concerns.

My current approach to situations like these are based on “Never Split The Difference” by Chris Voss and “SPIN Selling” by Neil Rackham. For me, I’m trying to identify what the other party _really_ wants, rather than what they _say_ they want.

All too often I’ve taken the other person at their word: “we want to reduce time to approval”, “we want all these features”, “we want to reduce operating expenses”. However, when time came to implement a plan to hit those goals, it turned out those weren’t the actual objectives.

A combination of sales, negotiation, and an attempt to identify the actual underlying need (belonging, recognition, autonomy, etc) has increased the hit rate.

But, at the end of the day, we’re monkeys wearing pants trying to squirt ideas at each other via flapping meat. Let’s just be amazed that communication between people can happen at all :)

I think the author is referring to characters in a Unicode string that are combined to form a composite glyph.

For instance, a large number of emojis are formed by combining two Unicode characters with a zero width joiner character. Skin tones are a notable instance, along with gendered occupation glyphs (female doctor, say).

It would be a simplifying (and usually correct) assumption to ignore such composite characters in a basic processing task.

I wonder if the Windows program compatibility settings would have helped. One should be able to mark a program as needing the 32-bit runtime. Googling tells me that the Windows XP SP2 setting should force 32-bit mode.

In this case (cybersecurity application), there is a complicating factor: you cannot trust that the environment is trustworthy. The out of memory condition may have been caused by malware to disable/degrade the antivirus sensor. For example, the malware allocates just enough memory that further OS allocations fail, but it has enough memory to accomplish its task then terminates to allow normal system processing to resume.

Under that scenario, the antivirus sensor should be able to take some action (log, likely) that a malloc failed, and possibly even try to recover memory and identify the risk.

But beyond that narrow use case, you’re right.

That is true, but that would be the definition of +. The OP is referring to the application of that operator to its arguments, which (depending on semantics) could also be a set of sets, or it could be a rewriting (ie, time based) process.

Just thinking out loud, this feels a bit like the problem ML’s module system is meant to solve: allowing the specialization of modules without needing to uncover the internal details of the implementation. I wonder if some of the same machinery would apply in this case. One would likely need a typed linear temporal logic theory to make it work.

It would seem that the problem is the notion of composition is underspecified in this domain. My intuition would be that one needs a different mechanism of composition aside from the most obvious “use basic logic operators to combine two unrelated logic statements”.

It’s unclear what “the composition of the two systems” really means. Are they running in parallel with no interaction (akin to two AWS instances in different data centers running each program)? Are they running in parallel with superficial interaction (two threads in the same process)? Are they running concurrently with mediated interaction (coroutines)?

The nature of how the programs are composed necessarily would influence the nature of how the specs should be composed, I would think.

Finally, maybe the fault lies with the logic system, rather than the problem?

As a hiring manager in the security field, a tip would be to include contact details that would allow people like me to reach out and discuss opportunities :)

I've just started reading "Agile Conversations" [1], and I found it's a nice complement to the other books mentioned in the thread. It's a little idealistic at times, but I like the focus on shared understanding and aligning perspectives. I used a couple of the approaches from the book quite recently and found that it kept the discussion focused on improvements rather than blaming.

[1] https://www.amazon.com/Agile-Conversations-Transform-Your-Cu...

Everyone is entitled to their dating preferences, but not everyone is entitled to their ideological consistency.

I’m currently out of the dating pool, but I had my share of preferences at that time and my potential partners did too. Preferences aren’t the problem, holding two contradicting beliefs is (it’s ok to discriminate based on unchangeable properties when dating, but wrong when setting salaries).

And I will follow the regression further to fully admit that my desire for rationality is itself a preference and not an unmitigated good.

People choose to grow and maintain mustaches, they are choices not an invariant.

But point taken.

I was with the sentiment, up to this line (which may have been in jest): “I’m a busy woman, I haven't got time to accidentally date a Virgo.”

So, you won’t date a person due to a characteristic that they can’t change or had any agency in choosing, while simultaneously decrying racism.

I just wish people could find peace...

I appreciated your earlier comment that talked about how you used signed distance functions to make the virtual joystick slightly expand. I used that as inspiration for some terrain generation in a very basic game I’m making to learn the ECS design pattern. So far, it’s working really well!

Thanks again!

As a Canadian who lived outside the country for a few years, I would say that most Canadians* are ignorant of the unwritten rules that underpin our culture, just due to the fact it’s hard to see the arbitrary choices that lead to our current society without deeply experiencing another.

It’s not malicious, it’s misunderstanding.

Ask for feedback on your perceived missteps (prefer “what” and “how” questions), and you’ll likely get answers. I also believe that it will lead to a learning opportunity for both parties.

* I would add that you could replace “Canadian” with any identity that has any sense of isolation.

Not the author, but I think the article indirectly talks about the liquidity in the markets being far higher than it has been in the past.

Further, if there is a stampede for the exits, there still have to be buyers on the other side of the sellers. Those buyers will undoubtably include active managers along with those indexers with different time horizons and/or braver constitutions. Both will likely be rewarded for their patience.

The author might be referring to the recommendation to run a program that's instrumented with Application Verifier under a debugger, which WinDbg is one of many.

From the article: “What he omitted to mention was that bitcoin has been operating successfully for almost ten years now, with no confirmed cases of fraudulent transactions.“

I think you have to stretch the definition of “fradulent transaction” to the breaking point to be able to make that claim with a straight face. At best, we have a definitive record of every fradulent transaction ever committed with Bitcoin, which is progress of a sort.

It's hard to share, unfortunately, but I would recommend trying it out yourself regardless. The journey was more rewarding than the destination, at least for me.

In my case, the destination was a very simple Forth interpreter that read input from the serial port and sent a single packet over the virtual NIC interface. There are so many ways to go, that just happened to be my choice.

It would be my pleasure :)

I'll refer to jonesforth [1], but I think the lessons apply to the other Forth's I've seen.

The main core of a Forth is generally written in assembly to bridge the specifics of a processing unit and the canonical Forth words. For instance, most control flow words are defined in Forth, but a couple critical ones are implemented in assembly and "exported" up to the higher level words. [2]

The main task of the core is to bootstrap to a sufficiently powerful yet abstract dictionary of words that will allow a full Forth to flourish. But to get there, you'll have to make a lot of choices that will be constrained by your chip (Intel x86, x86_64, ARM, Z80, etc). The big one is type of interpreter (direct threaded, indirect threaded, etc).

In jonesforth, check out the docs and implementation of NEXT [3]. The choice was guided by a quirk of the Intel instruction set that allowed loading the memory pointed by esi into eax and incrementing esi all in one step; further, Intel x86 allows an indirect jump to the address stored in a register (eax). Not all instruction sets support this pattern, you'll have to experiment and investigate for various chips.

That choice is a critical one, but it's one of many. Where do you store the dictionary of words? How do you implement DOCOL? What registers will you preserve? Why? What instructions will you expose? Which ones will you hide? Will you allow new words to be created with machine code?

In C, much of this has been decided by others decades ago (existing operating system ABI choices, mainly). In Forth, you can try things out and only be restricted by the chips, which is what all of us are ultimately constrained by, even fancy-pants languages like Rust and Go :)

Once you get past the core into Forth, some of the computer details recede, but you usually have to be somewhat aware of how you are using the system, far more than modern programming languages. Forth is the ultimate deep-dive "language" [4], but that is as much a curse as a blessing.

Basically, use Forth for the understanding it provides, then go back to making good software in typical languages aided by the enlightenment you've attained :)

[1] https://github.com/nornagon/jonesforth/blob/master/jonesfort...

[2] https://github.com/nornagon/jonesforth/blob/master/jonesfort...

[3] https://github.com/nornagon/jonesforth/blob/master/jonesfort...

[4] I've actually stopped calling Forth a programming language; programming system captures the idea a little better, I find.

As someone who felt that C was the path to knowledge for how modern computer systems "work", Forth and QEMU have become my "stretch challenge" for those with the motivation to tinker.

For me, working thru the resources on the OSDev wiki by taking jonesforth and linking it with the bootstrap from the "Writing an OS in Rust" tutorial (https://os.phil-opp.com/) really showed me how far C is from the hardware, and how much closer Forth connects to the idiosyncrasies of a computer system. Further, the immediacy of the Forth REPL can help with little experiments and building up the understanding of how much a machine's architecture influences code/data structures, opcode choice, privilege management, etc.

Plus, understanding Forth will bend your brain in a very strange but positive way :)

Looks like it prioritized historical locations over nearby locations. The little clock icon usually represents a prior location that was selected.

Could be an interesting design approach to know which locations are "fungible". I.e., one Wawa is as good as another, but your parent's house isn't a replacement for mine [1].

[1] I'm sure your parents are very nice, of course :)

I could be wrong, but my understanding of some sound cards is that they have essentially a single memory buffer that they are reading from when instructed to play a sound. Most sound cards let the OS split the buffer into two halves and raise an interrupt when one half of the buffer completes playing.

Interrupt prioritization doesn't help much, because the sound data is likely being generated from user mode, and the playback complete interrupt is being handled in kernel mode, which would require a transition back for further processing. When receiving data from a network card, no transfer back to user mode is required and will have implicit priority over sound generation. Therefore, network processing is likely to starve out sound generation barring choices like those described.

(This is somewhat hearsay, corrections welcome :))

There was just a story in CBC News about one of these devices discovered in New Brunswick, Canada in the 50's; http://www.cbc.ca/news/canada/new-brunswick/thing-in-the-woo...

There was a fair bit of cloak and dagger to recover the device at the time, nice to see the veil pierced a bit to get the history on it.