Your comment seems to miss that the author is speaking about technical drawings, not sketches, in particular this part:
> And I would argue also that this scarcity of ability was already a problem for the last 100 years. The whole iterative process of ideation (ie. designing, sketching) gets so much less intuitive, if one has to pull out a ruler first, or boot up his machine.
You mention sketching explicitly, which is exlcuded by the author. And making technical drawings without a ruler seems insane to me.
> In dev-speak, removing hand-drawing from the skill set of architects entirely is as if you were deliberately removing HMR from your local web dev-setup.
That would be true if you removed sketching, but removing hand-drawn technical drawings is more like replacing hand-crafted optimized assembler code with an optimizing compiler.
Requires PayPal or credit card. The suggestion was to pay with your Steam Wallet or whatever payment method already used when you buy a Proton-based game on Steam.
IMHO this supports the original point that payment via Steam would be an upgrade:
Sending cash to a postal address isn't low-effort nor low-risk.
Payment by cheque is something I have never done, nor would I know how to do it. I'd have to ask at my bank -- not low effort. I don't know if I'm an outlier here but I have never heard from any of my peers who ever did such a thing.
The same or even worse is true for international money orders. The whole concept of making a money transfer to a postal address is something I have never heard of. Where's the IBAN?
The Wine team is right to put even PayPal before all of these.
Yes, I do. It just means that you have to manually "recharge" your Steam wallet when it runs low. That's some effort, but it limits the possible damage if something goes wrong.
Actual application code was hardwired, entered manually with switches and lights, or with punch cards. Later, when ICs were sufficiently advanced, mask-programmed ROMs/PLAs.
Electrically, essentially what happens in most mask ROMs, but as a circuit board that allowed you to solder in a diode or not in each bit location in order to specify a 1 or a 0.
My advice would be to consider the possibility, not necessarily to stay out of the physical world. For some, those physical details may be the fun part. Some hate verilog. Some want to put it on an FPGA, some don't. I, personally, moved away from FPGAs due to bad documentation (looking at you, Lattice).
An alternative to Verilog is RTl simulation in a higher-level Language, or even higher-level Simulation.
Just remember that you can't define what is "fun".
Sorry for being ignorant of the basics, but how does the following work?
> However, seg-ments of code that are provably free of garbage collection
> have deterministic timing and can satisfy hard timing con-straints, as they
> are certainly not interrupted by garbage collection.
You are only ever "certainly not interrupted" if you turn off interrupts, which requires a high level of privileges. And not being interrupted still does not mean you have uncontended access to main memory or shared caches, which is a relevant factor for hard real-time. Nor do you have uncontended access to execution facilities (e.g. multipliers or floating-point ALUs), but at least for those you might be able to find an upper bound even for contended access.
Well, you're guaranteed not to be interrupted by garbage collection, which is the point here. Segments of code that are provably free of garbage collection can satisfy hard timing constraints, but that doesn't mean that they just will. It's a paper about garbage collection; addressing all the other things that need to be done to ensure compliance with hard real-time requirements is clearly outside the scope of the work.
I'm speaking a little outside my wheelhouse here (experts, please jump in), but my understanding is that if you have actual hard real-time requirements, you very well might turn off interrupts, multithreading, etc. and work with uncontested access to CPU/memory resources during time-sensitive parts of your code, as needed.
But that's still "draw the rest of the owl" category of complexity, and you probably can't really get hard real time on an ordinary kernel.
At that point you might as well take a look at runtimes that have a GC and is hard real time, which exists for the JVM. So not sure if it's really that valuable to separate out GC, especially when there are many other functions that can run much longer than expected (e.g. think of stack unwinding).
It's a curious sentence and one of only two to mention timing, the other being the introduction's mention of the "unpredictable timing" of garbage collection.
Obviously it is true in a single threaded system. If the one and only thread executes a basic block of instructions, none of which call into memory management, or call any functions which might do that, then it holds that it's not interrupted by garbage collection.
If there are threads, and a stop-the-world discipline for GC, then obviously not.
Note that garbage collection itself can have a switch, not involving disabling interrupts. Of course, you wouldn't want to insert that around every block that doesn't need GC. I'm just mentioning that in order to note that we don't a heavy hammer like disabling interrupts in order to momentarily disable garbage collection.
When GC is disabled, it is still possible to allocate objects, but no garbage collection passes are invoked to reclaim storage. This means that if the allocator has exhausted the available heaps, since it is not able to run a garbage collection pass, it has to ask the system for more memory for a new heap.
I've used a switch like this around calls to a Yacc-generated parser, due to the Yacc stack being invisible to the garbage collector; newly allocated objects could be prematurely reclaimed as they are being "laundered" through the Yacc stack before being nailed into the abstract syntax tree.
> Obviously it is true in a single threaded system.
But only if you disable interrupts, right? Of course, if you are working that close to the hardware, it makes sense to include "no interrupts" in your definition of "single threaded".
> Note that garbage collection itself can have a switch, not involving disabling interrupts.
I don't understand this. If you get thrashed with interrupts then no switch will remove the overhead of the interrupt handler, so you'd need an upper bound on the time for that handler AND the frequency of hardware interrupts to achieve hard real-time.
The only reason you'd need to disable interrupts to be sure that GC is not called over some block of code is if interrupt service routines are allowed to invoke GC.
For that to work, thread-like concurrency issues already have to be solved in the run-time.
Separately from that, we can have a system in which interrupts are allowed to call into the garbage collection module in order to allocate objects from an atomic free list, but a garbage collection pass is not allowed in interrupt context. (Allowing garbage collection passes, even if ephemeral, in interrupt context strikes as a bad idea because you generally want interrupt context to do as little work as possible.)
Now if we care about some block of instructions executing with absolute minimal delay then we do have to disable interrupts (at least local interrupts on the processor where that block is executed). We don't want the code to be interrupted to service any interrupts. No timer interrupts, no network interrupts, nothing. It is not related to GC.
I'm working on a similar thing, but due to various problems I encountered (auto-grading, scheduling, guidance, ...) I have, for now, concentrated on making a curated collection of problems / exercises. It's not yet a generator but rather "one of each kind of problem".
The idea is that _any_ user-facing tool, whether an app, worksheet generator or whatever, will need something like this for content, so I'm making this available for free and hoping for others to build on top of it.
I'm sticking to university-level stuff because I feel that school-level, especially math, is over-saturated already.
Technically, it is currently built as a React app, but that is mostly me sticking to tools that get out of my way. Generating PDFs or Anki files should be relatively straightforward.
Nice! University-level math would be great. That is my end goal as well, but I probably won't get to that until the end of the year. I am focusing on lessons that my kids will use, then switch focus to ones that I will use. Do you have it hosted somewhere? Or can you add some details/screenshots to the readme?
Everyone did accept that because when you needed information from a page that pulls that shit, you don't have a choice, and when you did have a choice, all the others did it too.
Nowadays people just ask ChatGPT for the information they need so they don't have to visit those awful sites anymore.
> That's just because corporations got greedy and made their apps suck.
It is true for me with Linux. I code for a living and I can't change anything because I can't even build most software -- the usual configure/make/make install runs into tons of compiler errors most of the time.
Loss of control is an issue. I'm curious if AI tools will change that though.
> HN, and firefox users, can never decide where the money should go or what the goals should be.
Without ever having dealt with this problem, it sounds like an embarrassingly solved problem, in the sense of: He who gives the money, decides where it goes.
The other half is to provide features that are actually detrimental if you don't want them as plug-ins / extensions / whatever. Pocket is an example for this. Firefox OS is not because it's not force-bundled with Firefox to begin with.
> They're switching to Chrome because they just don't care about being fucked up the ass, or worse, they secretly want to be.
The point where you stop trying to understand your users is the point where you start losing them.
> And I would argue also that this scarcity of ability was already a problem for the last 100 years. The whole iterative process of ideation (ie. designing, sketching) gets so much less intuitive, if one has to pull out a ruler first, or boot up his machine.
You mention sketching explicitly, which is exlcuded by the author. And making technical drawings without a ruler seems insane to me.
> In dev-speak, removing hand-drawing from the skill set of architects entirely is as if you were deliberately removing HMR from your local web dev-setup.
That would be true if you removed sketching, but removing hand-drawn technical drawings is more like replacing hand-crafted optimized assembler code with an optimizing compiler.
reply