It took Intel seven years to put those earlier machines into full production, which contributed to it losing its lead to Taiwan Semiconductor Manufacturing Co (2330.TW), opens new tab. Intel struggled with the reliability of those previous EUV models in the initial stages of production.
Um no, that's Intel trying to shift blame for its own botched 10nm process. Did that even use EUV? I kind of recall not.
I'm satisfied. Virmach has had ups and downs but their network is fast too.
If you want something Hetzner-like in North America, you might look at OVH. They have a data center in Beauharnois (BHS), Canada, which is near Quebec. It's not too different from using a server in the Northeast US.
That article is almost 4 months old and yeah, the internet in EU is better than in the US. But you can get US plans with plenty of bandwidth. I've been happy with buyvm.net and there are many others. Hang out on lowendspirit.com for a while to get a sense of things.
Wait, if you have the old edition on your kindle, do they reach into your kindle and change what is there? Or do they just change the version in the store to the new edition, preferably with a new ISBN, if Kindles have ISBN's?
I remember about the Roald Dahl thing and it seemed pretty clear which edition people would be getting. And some of this stuff (according to another internet poster I mean) may have been intended to keep the books in copyright longer rather than to merely mess with the content. Blyton died in 1968 so her stuff could enter the public domain in the next few decades otherwise. That's nefarious too.
I remember for sure that Huckleberry Finn had the N word. Maybe little kids shouldn't be reading it, I'm cool with that, though I read it as a kid myself. But grown-ups who do read it can deal with an unexpurgated version.
Scheme has call/cc but standard Lisp (i.e. Common Lisp) doesn't. Hmm, Rust async is like C++20 coroutines, so they can only yield from the outermost level of the task etc.? (Added: C Protothreads also come to mind). That sounds constraining even compared to the very lightweight Forth multitaskers of the 1970s. Python's original generators were like that, but they fixed them later to be stackful coroutines. ~~And do you mean there is something like a jump table in the async task, going to every possible yield point in the task, such as any asynchronous i/o call? That could be larger than a stack frame, am I missing something?~~ (No that wouldn't be needed, oops).
Setjmp/longjmp in C had some predecessor with a different name, that went all the way back to early Unix, way before C89. It was routinely used for error handling in C programs.
I've implemented Lisp (without call/cc) in C using longjmp to handle catch/throw. It wasn't bad. Emacs Lisp also works like that.
I had been pretty sure that delimited continuations were strictly less powerful than first-class continuations, but I'll look at the paper you linked.
I found some search hits saying you were supposed to implement signal handlers in Rust by setting a flag in the handler and then checking it manually all through the program. Even C lets you avoid that! It sounds painful, especially when there can be asynchronous exceptions such as arithmetic error traps (SIGFPE) that you want to treat sanely. But I haven't looked at any Rust code that does stuff like that yet.
Hmm, I wonder if it's feasible to use the Boehm garbage collection method in Rust, where the unsafe region is limited to the GC itself. Of course it would use pointer reversal to avoid unbounded stack growth. Of course I don't know if it's feasible to do that in Ada either.
Longjmp in C is generally used for implementing exceptions or things of that sort, which is fine. Even Ada and Haskell have exceptions. C++ has them too, though maybe that doesn't speak in their favor as much. Rust lacks them, but so far that seems to me to be a shortcoming in Rust. Even those wanting unwinding of error value checking through the entire call stack could look at the C++ deterministic exception proposal which is similar to Haskell's ErrorT monad transformer.
Anyway, Rust has its own sort of call/cc thing as far as I can tell (not sure), in its async runtimes. There is a coroutine switching scheme underneath that, amirite? Where do the call stacks for the different async tasks live and how are they allocated? I've been wondering, "Comprehensive Rust" doesn't go into any detail about this.
Call/cc in its most general form is possibly evil, but delimited continuations, the most common use of call/cc, are perfectly cromulent as far as I know. My brain is not currently big enough to understand the topic but I'm going by some of Oleg Kiselyov's old writings, probably linked from here: https://okmij.org/ftp/continuations/index.html
I don't think the software matters much tbh. It's about payment aggregation, search hit aggregation, and for some "prestige" substack writers, actually getting paid by the platform.
The attraction of substack for at least some writers is that substack actually pays their more popular or prestigious writers. I don't know how many or whether there is a published list of them, but at least a few of them are getting paid rather well (6 figures/year or maybe more). If Substack is recruiting and paying Nazis, then that is of interest and concern. Most writers there aren't getting paid by substack, though they may have readers who buy subscriptions. That is open to pretty much everyone and the fanfiction saying "don't like, don't read" works for me here. Saying Ghost is a more attractive platform because it has more censorship is kind of a head scratcher. And calling Taibbi and Greenwald Nazis is ridiculous. Disliking the Democrats doesn't make someone into a Nazi.
That said, I don't personally like substack very much and am always glad to hear about alternatives.
There have been a bunch of other phones and devices using that style of keyboard. I used a Nokia E63 for years. Were they under license? What about the one Lilygo sells now? Maybe whoever manages RIM's portfolio just stopped caring. Anyway this is kind of interesting. I always liked that keyboard.
Concrete technical answer (one of many): imagine you have a list ("array") of 5 numbers, and you try to print the 10th number in the array. A secure language will say "error! it's a list of 5 numbers, there is no 10th one!!". C will instead print some random garbage (whatever happens to be in the part of memory following the 5 element list), or maybe do something even crazier (try searching "nasal demon"), without indicating that anything has gone wrong. There are many other issues like this with C. You end up with programs going completely into the weeds, turning control over to attackers, etc.
Abstract philosophical answer: Secure languages like Ada and (hopefully) Rust are designed to help you ensure the absence of unwanted behaviours, rather than just the presence of wanted ones. If you want behaviour X, the goal of old languages like C was to make sure you could write a program in which X was present. That was a big enough challenge in the old days that language designers stopped once they reached that point. If you don't want behaviour Y (let's say Y is a security attack), it's up to you to just write the program without behaviour Y. 50+ years of experience have shown that to be inhumanly difficult once the program gets complicated, so you really do need help from the language. Accountants invented double-entry bookkeeping 700 years ago for similar sorts of reasons: to keep small errors in complicated systems from sending the system into a nose dive.
Ensuring the absence of behaviours is the classic problem of proving a negative, so there are limits on how thorough the checking can be, and the technical features (like the notorious Rust borrow checker) can be difficult to use. But if you're willing to endure a certain amount of pain and runtime inefficiency (requiring the program to do a little extra work at each operation to make sure the result makes sense, like the example of the 10th element of the 5-element list), you can make programs much safer than you can in C.
Does that help?
Added: Rust is getting some flak because it is pretty new, is still a work in progress, has various unmet goals, etc. It's not fully baked yet but it is getting there (I'm studying it right now). Ada is an older language that is way more mature than Rust, but is more of a pain to use in many ways, so Rust is currently getting more attention.
I'll probably have to read through it or maybe the Ferrocene standard, but for now, Comprehensive Rust is pretty good. I've been busy today but hope to finish it soon. Is it really true as someone mentioned that Rust binaries are always statically linked? That has its attractions but I would hope it's controllable. Can you use the regular linker (ld) with it?
I know that the "project" approach to learning a language works for some people, but I've found l greatly prefer to read a book from beginning to end before undertaking any projects. It helps me start out with a clear picture. I'm finding "Comprehensive Rust" to be fairly good so far. Thanks for all the help, everyone.
Um no, that's Intel trying to shift blame for its own botched 10nm process. Did that even use EUV? I kind of recall not.