The Thinkpad also likely cost far more than $600 when new. Even a several-year-old flagship laptop is going to be superior in some respects than a brand new laptop designed and produced to cost as little as possible.
Other than possibly proper ABI, and yes a tiny handful of file operations that could theoretically block not available through io_uring, like ioctl and splice, Linux has the rest.
In security? Not really, unless you are doing immutable deployments with rootless containers, no shell access, which at the end of the day isn't UNIX any longer.
And which Linux exactly? Plus unless you're doing C or C++, most likely aren't using those APIs.
Anyway, the differences of bare metal servers don't matter in the days of cloud where the actual nature of the kernel running alongside a type 1 hypervisor hardly matters to userspace.
It is the same in Canada [1] yet I frequently see beer sold in "US pints" over here. I assume they do it so they can advertise cheaper prices (the amount being smaller). Some places will write the glass size in ounces, but some won't.
Also Canadian. I don't often see "pint" on the menu, usually something like "16oz." Evidently restaurateurs and bar owners are wise to the law. Though I am pleased when I see "20oz" on the menu!
I kind of understand the logic by not serving 20oz and saying "pint". Customers might avoid a place because their "pints are more expensive", when in reality that place is also serving them 4oz of extra beer. A bit like the classic 1/3 lb cheeseburger being "smaller"[1].
Annoyingly, I do find that servers will often refer to their larger size beer as "pint" regardless of whatever the menu says.
I have a buddy who used to call Weights and Measures on bars that passed off US customary pints as "pints". It is illegal, but enforced largely by complaint.
Also in the US (probably due to lack of training and the customer too embarrassed to complaining) tend not to fill it the brim (and so not even 16''). I've seen 2-3 inch heads and asked them to top it up. They look at me as if I've just insulted George Washington.
Your pubs kindly return the favor when we order whiskey. As Hunter S Thompson is reported to have quipped in a bar your side of the Atlantic: "What is this, a sample?"
Personally I'd have us use what the Royal Navy used to serve its rum ration in, the half-gill. This is 1/8 of a British pint or 71 millilitres, and the rum would have been a minimum of 54%!
Fractional gills were the pre-metric shot measure in the UK, but they were still pretty stingy. 1/6 gill in England, 1/5 or 1/4 gill in Scotland, and 1/4 gill in Northern Ireland.
A pint in the Netherlands usually is 500ml. In very rare cases, but only in real pubs (not mass market "Irish" pubs) you get an actual pint. So you are cheated out of about ~68ml in that case. Vs the US you get a few ml more.
As far as I knew, Netherlands pubs typically sold:
- 200ml "fluitje" (little flute)
- 250ml "pintje" (little pint), often sold in a "vaasje" (vase, a tapered beer glass). This is the typical beer measure: https://nl.wikipedia.org/wiki/Pintje "Het bestelde glas pils heeft doorgaans een inhoud van 25 cl"
The Maß is only a thing in Bavaria and strongly Bavarian-themed places, and almost nonexistent for bottles or cans anywhere in Germany. Faxe (which is Danish) sells one liter cans and some Czech brands sell or used to sell 1.5 liter plastic bottles - that's about it. The next common size is 5 liter mini kegs.
In the 19th century, at the same time they went stone-mad (and redefined the hundredweight as 8 stone or 112lb), the British redefined the pint as 20 oz.
After this point, there was no where the whole world round where a pint was a pound.
(The US standardized on the wine gallon, so a US pint is and was 1.04 lbs.)
It's not completely uncommon to be offered 16 oz or 20 oz as options in the US. But I see it more at "fast casual" restaurants than bars or more upscale restaurants.
And of course, what an "ounce" means may vary. According to Wikipedia "An imperial fluid ounce is defined in British law as exactly 28.4130625 millilitres, while a US customary fluid ounce is exactly 29.5735295625 mL, and a US food labelling fluid ounce is 30 mL."
Americans don't claim to use imperial weights and measures; they use customary weights and measures, which were also used in the UK prior to the creation of imperial units with the Weights and Measures Act 1824.
The origin of US Customary units is British, even if the US, Liberia and Myanmar are the last countries still using it. The UK has almost entirely adopted metric (yards and miles are still used for measuring distances on roads and pints are still used for milk and beer, and the last government made the eccentric decision to permit pints for wine, which no producer used because they couldn't get the bottles), but these systems of units have identities beyond whether or not they're in use anywhere.
EDIT/CORRECTION: Milk is sold in multiples of 568 mL, so while the quantities are pints, the measurement is metric.
> EDIT/CORRECTION: Milk is sold in multiples of 568 mL, so while the quantities are pints, the measurement is metric.
What distinction do you intend to make by that? 1 pint is 568ml.
If you mean in labelling or something, no, they're marked 1/2/4 pints. Usually also with litre markings. You can also get metric sized bottles, i.e. on the supermarket shelf you'll often see one brand's 2 pint bottles next to another's slightly smaller 1l bottles.
The supermarket price labelling will be in £/litre, regardless of whether the bottle's pints or not, if that's what you mean?
Beer and cider are the only drinks that are legally not sold by metric volume in the UK. They have to be served by the pint, 2/3, 1/2 or 1/3. Every other drink has to use metric.
But that just means the quantity has to be expressed in metric units, possibly in addition to imperial, correct? E.g. I currently have a carton of milk in my fridge that’s labelled “2272ml 4 pints”.
Not for alcohol measures. Beer and cider have to be sold in pints, and there is a list of allowed sizes used for other drinks. Also the size of the standard measure used for spirits needs to be displayed on a sign at the bar.
Not really. The UK uses imperial units for most of the things you use units for in daily life (roads, cooking, drink sizes, body weight, utilities, land area...), even though they theoretically converted to metric. Canada is similar.
> The UK uses imperial units for most of the things you use units for in daily life (roads, cooking, drink sizes, body weight, utilities, land area...)
Not really. Old people might cook with funny old temperatures/measures and weigh themselves in stones, but it's fading out, contemporary cookbooks and gym culture are all metric. I've literally never seen a utility bill in anything other than metric (even if it's slightly weird metric like kWh or cubic metres of gas).
_Human_ body weight. I grew up measuring everything in kilos apart from people, which has I guess what amounts to its own wholly idiosyncratic scale, the stone, that no one I've since met outside of the UK has heard of.
I don't know why really, it's just 14lb, why does the US/Canada just stick with very large numbers of pounds instead of breaking it up as with others?
Kilograms seem more and more common for human weight too though, largely driven by fitness apps & communities I think. I doubt children in school today are accustomed to stone; only pounds and ounces for birth weight perhaps, but even that is metric medically and converted for the parents' familiarity these days I believe.
No medical professional in Blighty weighs people using imperial measurements. The only people who really use them are the elderly and (bizarrely) the type of crappy slimming magazine seen at supermarket chekouts...... The kind satirised by Viz as titled "Less Cake, More Exercise".
As far as I can see, at least some of the cost-of-goods-sold of a token is dictated by GPU costs (both purchase price, and operational costs). Surely if Nvidia continues to produce increasingly sophisticated GPUs, the monetary value of each token will decrease? Seems like a strange incentive for Nvidia to offer their employees.
EDIT: If the tokens are not intended as a form of perk/benefit as others have interpreted, I guess my point does not count.
It's definitely true that they do not have access to the original OS/2 source - this has been confirmed by people from Arca Noae in various interviews/presentations I've seen. I've never heard a definitive explanation for why, but two reasons are usually speculated:
1) Due to the amount of third party code in OS/2 (most notably, the DOS and Win 3.x layer) that IBM is unable to license out the code, or unwilling to go to the trouble to figure out the legal implications.
As far as I know, yes. There were no changes made to eCS which required source - everything was implemented as drivers, or layers on top of the base OS.
I have not heard or seen any direct confirmation of this anywhere. If you have, I would really like to know. I am looking at a follow-on review and this would be great background info.
> most notably, the DOS and Win 3.x layer
I think what you put in parentheses here is the real reason.
IBM probably still has the source. It seems to be methodical, unlike say Symantec which lost the QEMM and DESQview source.
But IBM and MS co-developed OS/2. MS has joint ownership of this code.
MS has a 50+ year history of being a deeply dishonest and unreliable company. It hates FOSS and only releases what it has to. MS-DOS 4 only got out became someone found it and made it public.
Satnav Nutella has no more understanding of this than the Queen of England. He will do and say whatever is needed to make Number Go Up.
MS releases tiny token gestures to make the incomprehending loud FOSS advocates believe them. Notepad, Calc, ancient DOS releases... nothing that matters.
It won't release Windows 3 because some of that code is still in Windows today.
MS does not love Linux. WSL2 is an embrace-and-extend tactic. If MS had a real clue left then WSL1 would never have been a product: it would have just extended the NT kernel POSIX personality to run Linux binaries.
Remember the core of Windows is the NT kernel and it can natively run OS/2 binaries and Unix binaries.
It doesn't because MS turned it off. NT is a version of VMS with native Unix and OS/2 binary support and a GUI built on Windows 3 code and MS won't let that code out. If it did the ReactOS people could make a ReactOS that was Good Enough. The WINE people could make a seamless one that make .EXEs a 1st class Linux citizen.
MS is terrified of that because it doesn't have the skills to do the equivalent any more, and WSL2 is the existence proof of that. It couldn't even get systemd working in WSL2 until it hired Poettering to do it. Then he stayed there just long enough to get the money and he's off out again.
The reason IBM won't release the OS/2 source, even to Arca Noae, is Microsoft.
Also, around the 25 minute mark, Rosenthal points out that the Workplace Shell source code "no longer exists in one place anymore", so I do think that there are problems with finding all the source for the OS.
1) There's a bunch of commercial software which only runs on OS/2. A lot of it was vertically integrated software either developed for a specific customer by IBM, or developed in an "IBM shop". The ticket machines for the New York subway were powered by OS/2 until relatively recently. There are also supposedly a bunch of banks which have OS/2 dependencies.
2) There are still hardcore OS/2 fans who use OS/2 as their main OS. As you correctly assume, getting something like a modern web browser to run on OS/2 is a challenge, but some people grin and bear with it anyway.
3) Strange people like me who run things like OS/2 on spare computers or VMs for the novelty value.
> So to me it seems that we don't want abstractions when trying to study certain things about a whole system. Instead, we want to view all of its components and then build our understanding from there. Abstractions hide the things that we care about.
I disagree. My experience is that most problems require a very thorough understanding of a specific slice of a system. It is rare (again, in my experience) that solving a problem involves understanding the whole system. This becomes more true the larger and more complex the system is. Abstractions allow you to ignore the irrelevant pieces and focus on what matters.
In a well-designed (or "proper") abstraction, we can deal with it in terms of its public interface. Two things that break abstractions are bugs and performance.
If you have either of those, then abstractions can be worse.
Another thing that is bad is the wrong abstractions, or abstraction inversion (https://en.wikipedia.org/wiki/Abstraction_inversion), where a layered system hides abstractions at the bottom from layers at the top, that top layers would nevertheless like to use, and reimplement, poorly. This happens surprisingly often.
But overall, I generally think that well-designed and factored abstractions are better than no abstractions at all.
I disagree as well. Abstractions, or interfaces, define the contract between modules, and then you can reason about the system in terms of those contracts. Without the abstractions, you’d have to reason based on all the details of the whole program, which is obviously much harder. Abstractions are a form of divide and conquer.
Regarding the article’s point about diluting abstractions when new disparate features are required, a third alternative (to the two presented in the article) is often to provide alternative abstractions in parallel, each individually still focused and to-the-point, which prevents both changing and diluting the existing abstraction.
Regrading the article’s point about performance analysis, in principle you can specify performance guarantees for each abstraction. It’s more difficult to check them, but in theory a type system could even encode performance characteristics in an automatically checkable way.
I agree with this. One way that I will go further is to say that “understanding of the whole system“ is a pretty fraught phrase. One person‘s holistic understanding is another person‘s gnostic gobble-de-gook. Realistically, they are all essentially just abstractions bounded by a different stopping rule. Just because one person‘s view of the whole system does not include what the GOOGLE engineer writing the code had for breakfast does not mean that that can’t be reasonably included.
The issue I think people have is that abstractions do not announce when they are insufficient or porous. This means that an abstraction which is perfectly trustworthy without further inspection for many years can suddenly become hazardous without warning.
After reading the article I think the point stand. Not always but for example when working doing a RDBMS all the abstractions are active inhibitors and even hostile to do what should be done (easier) without all that.
And then you need to know that "no, all that IO sys call not do what you want, how yow want neither how is documented or even practiced by most" to take the most obvious case.
So, yes, this is a case where this quote is on point.
When Wirth talks about modules and abstraction I believe he was talking about what was known as the software crisis. In particular the observation that as programs size increases the number of possible interactions of program components grows quadratically.
Modules in particular and good abstractions in general make the number of interactions between components tractible.
The N^2 component interaction problem is real and it continues to cause problems.
Even with our best solutions there is room for improvement.
Last I paid attention there was a culture that had developed around the administration of CISCO routers because things that should be unrelated affecting each other is a real world problem for the administrators of those routers.
Any time something changes in siftware and something unrelated is affected this general problem is making it's appearance.
There is also a long term tension between abstractions and entire system simplicity. The wrong abstract or an abstraction poorly implemented can make things worse.
Wirth was talking about "modular programming", a term that isn't as well-known today as it once was. It's where Modula got its name, and there were entire conferences and journals that arose in response to the term's coinage. Ultimately the label "object-oriented" got a lot more mindshare, even to describe concepts that can be accurately described as modular programming and aren't terribly accurately described as object-oriented (generally lacking one or more of the necessary message-passing and "extreme late-binding" criteria required for O-O).
Technically, I prefer Rust but I understand people who find Go better suited for their work. For example, devops is mostly Go nowadays and that makes more sense than Rust (or Python).
But I've never, ever seen toxic behavior from the Go community. For Rust, it's the norm, sadly.
> After spending time on Apple’s M1/M2 Macs (coming from a large x86_64 desktop), going back to x86_64 feels like a regression, both in performance and battery life.
I have a Thinkpad X1 with a Lunar Lake CPU, running Fedora. Battery life is comparable to the Mx Macbook Pros I've owned or used. Performance is not as good on synthetic benchmarks, but more than good enough for my needs, even when running VMs or containers.
I have a Strix Halo laptop, HP ZBook Ultra G1a. (HP is a weird brand. I'm not a loyal customer, but every once in a while they create a product with really good reviews, I buy it, and it delivers.) Performance is almost on par with Apple's best, but battery life under light load is much worse :P, 6:30 or so.
Under full load, battery life is an hour or so, similar to Apple actually! If the numbers I've seen are correct, they also use a lot of power under full load.
Also, thank $deity for engineered noise signatures. Whooshing is not so bad. Whining fans are the worst. Last heard in better laptops several years ago.
The VT1xx keyboards used linear switches, you may want to look at modern mechanical keyboards with linear switches as a rough approximation. Having tried typing on one in a museum, I recall the VT1xx as relatively scratchy compared with more modern keyboards, although that could have been a wear and tear issue.
The keyboards of the VT2xx/3xx series are awful, and the later ones had rubber dome keyboards which are among the nicer rubber dome keyboards I've tried. I own both a VT320 and VT420, and managed to get a new old stock keyboard for each.
reply