My first, and primary, programming language was C# which includes probably too large a standard library. It was definitely a surprise to see how minimal/simple other standard libraries are!
But they're there. I would much rather have a stdlib option which isn't as good as the most popular third party solution, than not have an stdlib option at all. You can't always count on being able to install stuff from pypi, but you can always count on the stdlib being present.
Broadly speaking, maintaining a big std lib is a huge amount of work, so it makes sense that a language team is conservative about adding new surface to a stb lib which they will then have to maintain for a long time.
The work involved in maintaining a standard library is things like bug fixes. A larger standard library (or multi versions) means there's more likely to be bugs. You also have performance improvements, and when new versions of the language come out which has features to improve performance, you will most likely want to go back through and refactor some code to take advantage of it. You will also want to go through and refactor to make code easier to maintain. All of this just gets harder with a larger surface.
And the more stuff you pack into the standard library the more expertise you need on the maintenance team for all these new libraries. And you don't want a standard library that is bad, because then people won't use it. And then you're stuck with the maintenance burden of code that no one uses. It's a big commitment to add something to a standard library.
Every library is a liability especially in terms of api. There are many example where the first take on a problem within a std lib was a bad choice and required a major overhaul. Once something is in standard library it’s literally impossible to take it back without breaking the world if you don’t control api consumers
Yes, in python they break something at every release now. It's terrible. It mostly is because they remove modules from their standard library for no good reasons.
For example they've removed asyncore, their original loop-based module before the async/await syntax existed. All the software from that era needs a total rewrite. Luckily in debian for now the module is provided as a .deb package so I didn't have to do the total rewrite.
edit: as usual on ycombinator, dowvotes for saying something factually true that can be easily verified :D
The code is under the open-source PSF license. You can vendor or repackage it as you wish rather than rewriting your dependents. The removal is mostly about ensuring that nobody will try to hold them responsible for any more maintenance (plus they can, for example, drop tests and have a faster running test suite).
The thread is about the code in the std lib being a huge amount of work because the code in the std lib needs to be kept working with new language releases.
And then you answered about downstream code breakage totally outside the std lib.
What would that entail, just a package whitelist? A few renamed packages? In the python 3 transition they renamed urllib2 to just urllib, but now it's almost a dead battery too and you want to use requests.
Honestly the problem was they did not go far enough. They hoped to have a minimal churn switch to avoid getting locked into bikeshedding for the rest of time. However, there was so little user user facing improvements that the required change hardly seemed worth porting. They also failed to initially offer any automatic porting tooling which could have increased adoption.
I will be forever mad that they did not use that as a breaking opportunity to namespace the standard library. Something like: `import std.io` so that other libraries can never conflict.
For a camera exposing onto Kodak 5254, probably the fastest available in 1975, blazing ISO 100 film stock. Yeah it’s dim for that. To your eyes as I understand it’s pretty well lit.
The photo nerd hacking tweak of note here was the pushing of the stock to 200 and using uniquely crafted NASA lenses built to photograph the dark side of the moon with not seen before aparture.
Arguably a youtube rending of a compressed digital source viewed on a computer screen falls short of a 1970s full cinema via film live viweing.
> Alternatively, users can also choose to purchase the Mac versions of Final Cut Pro, Pixelmator Pro, Logic Pro, Motion, Compressor, and MainStage individually as a one-time purchase on the Mac App Store.
Magnetic induction damping compasses have traditionally used a flat plate under the needle in order to arrest the motion of the needle. This component is not transparent. By removing the plate and adding the ring, you can see through the face, providing the benefits of a liquid damped compass without the possibility of a bubble forming.
Interesting, maybe new for pocket compasses. I had a marine plotting compass that used a massive copper cylindrical housing, with a sapphire glass bottom and window. It was very well damped. It was made in the 1940s, presumably when yachts were mostly wooden. (More modern boats would usually need significant compensation) or maybe it wasn’t for marine use? But anyway, it was a great plotting compass that I used extensively on my little fiberglass weekender sloop. Better than the westmarine garbage mounted on the cabin bulkhead by a long shot.
Lots of liquid damped compasses do not have a transparent base. The liquid is very good at protecting the needle (induction compasses often use a lock), prevents condensation, stabilises temperature, and is noncompressible for diving. Induction compasses tend to be used for fast reading whilst off-level, so tend only be useful for sighting compasses. TBH I am not sure even map compasses grain a lot from transparent dials, it is more that they are making the baseplate and top from transparent plastic and have no need to make the bottom from something else.
That's because the magnetic needle's orientation will only induce meaningful flux in a cross section large enough for it to have any damping effect. That braking effect is more or less proportional to the number of fieldlines cut and diminishes (from memory) to the cube of the size of the air gap.
It offers native x86, Windows on ARM, and Apple Silicon versions.
I think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that.
This is neat, and exciting that Windows emulation tooling is progressing! It seems like there’s a lot of work hardware vendors would need to do in order to make Win/Arm viable for game devs. I really wonder if that’s ever going to happen.
> I think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that.
It has been around for a while, circa 2021. They made a forum post when they released it.
You specified working with web and .NET Core (now just called .NET). Given the scope of modern .NET I don't think I can recommend a single book, but I've tried to order this in how I see them as most to least impactful for a dev.
For web dev specific guidance it's hard to beat ASP.NET Core in Action by Andrew Lock. Check out Lock's blog too at https://andrewlock.net, it's a great source of new features happening in ASP.NET. He does go into publishing an app on both Windows and Linux, with a decent guide to both. But you'll probably want to read through MSDN docs on that as well, I don't think there's a book that goes in very deep on that.
For generally writing modern C# using .NET, I like Code like a Pro in C# by Jort Rodenburg.
For a quick tour of modern C# features C# 12 in a Nutshell by Albahari is basically the reference guide. 12 is the latest, grab any of them from probably 7 up for a decently modern take.
The Phoebus cartel didn't collude just to make the light bulbs have a shorter lifespan. They upped the standard illumination a bulb emitted so that consumers needed fewer of them to see well. With an incandescent you have a kind of sliding scale of brightness:longevity (with curves on each end that quickly go exponential, hence the longest lasting light bulb that's so dim you can barely read by its light). The brighter the bulb, the shorter the lifespan.
Also, incandescent lightbulb lifespan is reduced by repeated power cycling. Not only is the legendary firehouse bulb very dim, it has been turned off and back on again very few times. Leaving all your lights on all the time would be a waste of power for the average household, and more expensive than replacing the bulbs more frequently.
Also lightbulb dimmers were a thing back in the day, so you could always buy more lightbulbs and lower the brightness of each to take advantage of that exponential curve in lifespan.
I love how capable these tiny N150 machines are. I've got one running Debian for my home media and backup solution and it's never stuttered. I'd be curious about exactly what machine they're testing with. I've got the Beelink ME mini running that media server. And I use a Beelink EQ14 as a kind of jump box to remote into my work desktop.
I'm not the author but my parents have pretty much decided they will never use a game console newer than the nintendo wii, but so far two of their wiis have died. Since no one is making wiis anymore, I decided to future-proof their gaming by setting them up with a mele quieter 4c [0], with the official wii bluetooth module attached over USB for perfect wiimote compatibility, running the dolphin emulator. Not every game runs perfectly, but every game they want to play runs perfectly AND it is smaller, silent, and consumes less power than the real wii.
[0] My experience with that mini computer: I bought two. The first one was great, but the 2nd one had coil whine so I had to return it. Aside from the whine, I love the box. If I could guarantee I wouldn't get whine I'd buy another today.
Would you mind sharing the Linux hardware platform security report ("fwupdmgr security") for those Beelink boxes, e.g. what is enabled/disabled by the OEM? N150 SoC supports Intel TXT, which was previously limited to $800+ vPro devices, but it requires BIOS support from OEMs like Beelink. Depending on HSI status, OSS coreboot might be feasible on some N150 boxes.
Happy to share the report from the ME Mini box (below). But the other one is running Windows so I can't help there. Thanks to this I was able to find I'd initially left off secure boot and was able to fix a couple of its suggestions at least, but if I'm understanding the HSI status and coreboot needs, there's fuses flipped that would prevent it.
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
Host Security ID: HSI:0! (v2.0.8)
HSI-1
csme override: Locked
csme v0:16.50.15.1515: Valid
Platform debugging: Disabled
SPI write: Disabled
Supported CPU: Valid
TPM empty PCRs: Valid
TPM v2.0: Found
UEFI bootservice variables: Locked
UEFI secure boot: Enabled
BIOS firmware updates: Disabled
csme manufacturing mode: Unlocked
SPI lock: Disabled
SPI BIOS region: Unlocked
UEFI platform key: Invalid
HSI-2
Intel BootGuard: Enabled
IOMMU: Enabled
Platform debugging: Locked
TPM PCR0 reconstruction: Valid
Intel BootGuard ACM protected: Invalid
Intel BootGuard OTP fuse: Invalid
Intel BootGuard verified boot: Invalid
HSI-3
CET Platform: Supported
Intel BootGuard error policy: Invalid
Pre-boot DMA protection: Disabled
Suspend-to-idle: Disabled
Suspend-to-ram: Enabled
HSI-4
SMAP: Enabled
Encrypted RAM: Not supported
Runtime Suffix -!
fwupd plugins: Untainted
Linux kernel lockdown: Enabled
Linux kernel: Untainted
CET OS Support: Not supported
Linux swap: Unencrypted
UEFI db: Invalid
This system has a low HSI security level.
» https://fwupd.github.io/hsi.html#low-security-level
This system has HSI runtime issues.
» https://fwupd.github.io/hsi.html#hsi-runtime-suffix
reply