HN user

temptemptemp111

-6 karma

Shadow banned on HN; Apologies for the inconvenience, but none of my comments are visible unless you sign in. They freely admit to manually filtering my comments here: https://news.ycombinator.com/threads?id=temptemptemp111#39185648

Posts0
Comments28
View on HN
No posts found.

To see more on "Project X", see the Phoronix article on it. At the very least, it would be resourceful if the Oxide devs had a chat with the Project X devs who have since given up - learnings can be had and time can be saved. And yes, coreboot itself is now untennable, but is also kind of a slang for the a category of deblobbed software.

I don't expect anyone to see my comments unless they're really looking since I've been shadow banned for many years now - so I appreciate your reply.

To be clearer regarding my questions:

- What happened to Project X (supposedly coreboot++ for latest AMD CPUs)? It seems dead, despite being more reported on than Oxide's attempts in working with AMD (to achieve the same outcomes, presumably - what's the difference?). Loads of well meaning people have approached this with virtue, innocence and skills; perhaps another approach is needed that fully respects the dynamic between the user, the chip manufacturers and the governments and banks they're in debt to.

- Does Oxide attempt to sandbox, completely remove or 'verify as benign' aspects like the PSP? For example, if someone could verify that the PSP cannot possibly be affected over the network, then peace of mind could be more affordable regarding things like supply chain attacks and bad actors with AMD/Intel/Apple management engine secrets.

Not referring to software lock-in, just hardware. And it isn't very nefarious like other hardware lock-in (serialization, see Rossmann Group). Just hardware on the rack-level: replacing oxide gear & upgrading oxide gear (not sure about repair, that could be easy). And if the offering were of a less blobby architecture, then many of us would be happy to pay a bit more for the hardware as a system. However, if the hardware platform is FOSS, then it won't be unnecessarily difficult to mix and match and integrate the Oxide gear with other DC-class gear.

What even is Oxide Computer? It makes no sense - it was publicized with all sorts of anti-blob, freedom, and posts about management engines and a sort of alternative to RaptorCS/IBM (which now has blobs again)... Yet most of that stuff is now buried/removed and Oxide Computer is just a hardware platform with unnecessary lock-in. For the bunker of the rich to be able to run their own mini-cloud? Sure. For anything else it seems like a bad design.

You guys keep saying this word "reproducibility" but I don't think you know what it means. Debian and Arch are more reproducible than NixOS.

No, not weird, it is called having good taste. For OLED that means DC dimming not PWM dimming - big difference. And with all of the Ryzen Thinkpads there is no excuse for not having ECC when all of the Ryzen mobile CPUs they're using already support it. I don't get the touchscreen thing, but you can always use one of those artist pads via USB and not affect your screen and be decoupled from the rest of your system (USB peripheral).

They do have lots of sensors that can be used... We have bad defaults and a not-very-skillful usage of said hardware. On workstations there are lots of options. In datacenters, there could be some dedicated hardware for it somewhere - and an skillful usage of said entropy being imported into each rack unit.

How to Learn Nix 5 years ago

Where is the evidence for this? Where is the evidence that you can and should mix config management all of the way down the OS stack? How many containerization concepts do we need? Docker, lxc, VMs, and now NixOS? If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again. I'm open to nicer restructuring of the Linux fileystem, but this is really re-inventing the wheel trying to polish over ugly parts that are ugly for a reason. Keep useful abstractions separate!

I disagree. ZFS is great on Linux. The killer feature of FBSD is its simplicity and lack of incoherence in focus, which all the Linux distros suffer from. People don't see to be able to differentiate between these issues: Linux distributions' diversity of features and options is not a problem - it is the lack of focus & coherency of their management. This makes it harder to help other people on the same distro, to collaborate about bugs on the same distro, etc... Then you read an OBSD/FBSD thread from developers who aren't really better than developers on Linux threads - and you see much more coherency; because of the coherency in the systems they're working on.

Agreed. Good support for compose currently, and swarm is usually overkill. With a bit more elegant HA functionality, docker-compose could be the go-to for many more. The comment below claiming he doesn't understand your comment reminds me of all of those who will say "well its not FOR production" - seems more like superstition than science.

What would you recommend for a Stripe-backed SMB who has to turn away dozens of users per month because they only have some kind of "bank card" (which is normal in many European countries now). This business doesn't currently have the budget to implement support for all of these card types (Stripe UK does have support for most of them, it seems).

Kobo is still the most open e-ink device ya? And yes, reading is so different from programming - for long hours reading, I still think e-ink is the best, but depends on ambient lighting.

Hey, I'm curious, would you mind turning 'showdead' on and replying to my comment here? I'm shadowbanned on here and would sometimes actually like replies in discussion with interesting comments like yours. Thanks.