Much of the open source movement has its roots in anti-corporate culture too. Given that open source is now largely funded by corporations is a win for the ideals of open source but also a corruption of the early ethos; It’s very easy to equate open source with corporatism.
systemd is a lot less complex than legacy init systems, in the Rich Hickey sense of systems that are linked together in irregular and noisy ways.
A million lines of C supporting 2k lines of declarative unit files is less complex from the user's perspective than 50k lines of custom bash scripts. Of course it would be better if it did the same thing in, say, 100k lines or in Rust, but perfect is the enemy of good. systemd exists today and it works fine.
Everything is regular, predictable, documented and easy to read. A file made for one distro only needs trivial changes to run on another. That's what simple really means. I would never go back to init scripts.
> Everything is regular, predictable, documented and easy to read. A file made for one distro only needs trivial changes to run on another. That's what simple really means. I would never go back to init scripts.
OpenRC, s6, rc.d (the BSD), are more simpler than the systemd ecosystem which is feature ladden and not easy to use on the common line. They are also way easier to hack upon, especially when you want to run a lean system (small vm, containers). systemd feels like running windows server for a small php application. The happy path is easy, anything outside of that is torture.
I did this with a Polaris Ranger EV that had 8x12v Lead Acid in a 2x4 configuration that produces 48V. Instead of going with more 12V batteries, I switched to two 48v BigBattery LiFePO4. In doing so, I dropped the weight by about 600-700 lbs. I use it in very hilly terrain so that weight makes a huge difference to me.
Additionally, the original batteries were not sealed and required maintenance. Each battery has two ports which need to be filled individually. On top of those ports are supports/braces and wires in an already inconvenient space.
I'm so happy to not have to deal with refilling those batteries anymore. That alone made the conversion worth it to me. Also, lead-acid doesn't necessarily last longer. The new (LiFePO4) batteries have lasted about as long already and (knock on wood) seem to be doing fine. Maybe it's because I don't have to top them off with distilled water?
Yeah, such a big difference. I had a similar choice with a skid steer and the lithium version adds weight into the rear of the machine in order to stay useful.
Tossed the lead-acid battery in my DR-Z400S motorbike, put a LiFePO4 in. The weight and mass placement difference was so significant that I had to re-set the suspension sag.
My DR-Z400S dual-sport motorcycle is like… 140kg?, kind of tall and narrow for a motorbike. The lead-acid battery is placed sort of high on a sort of fulcrumy point over the rear suspension. It's a very real difference. Didn't expect this dramatic a difference.
It's nice to do this for more than just the direct economic costs. The generator doesn't have to run 24/7 since the batteries absorb the excess power produced by the generator. This means less fuel wasted as well as less noise produced. I used to have two small generators that I could run (and team, if needed) but adding a battery component meant being able to sleep at night without a combustion engine burning fuel all night long.
Yup, even better if you power a separate battery charger with the generator, but let loads be handled by the battery+inverter. You don’t need to provision the generator for peak loads (which can be quite high), or even worry about high harmonic distortion from a cheap generator screwing with your electronics. It basically turns your system into a fully ‘online’ UPS.
Also, really handy for diesel gens which will ‘wet stack’ if you only run them for short periods or with light loads.
Provision a generator size which you expect to run say 6-10 hours at a time (at say 70-80% rated load) to fully charge your batteries, and a battery bank sized for 3-4 days of load.
Keeps your total gen hours much lower, much more efficient fuel wise (you can set the ideal load using your charger, and it will keep it that way regardless of increasing/decreasing loads), doesn’t require as big a generator if you have things like AC compressors, heat pumps, etc. with high start loads, and gives you a lot of redundancy and flexibility. It even gives you time to fix your gen or find/beg/borrow another if yours breaks, and you won’t need to keep the gen running overnight if you plan appropriately, so your neighbors will like you more.
Best of all worlds. Especially if you have natural gas, or get a tri-fuel generator and keep propane handy. Propane doesn’t go bad like gas or diesel can.
Well, looking at the mess that is most arm/arm64 SBCs, I understand why it’s nice to have a standard interface that can run (eg) grub. Can UEFI be much smaller? Also yes.
I'm currently using the Radxa Q8B, which already includes EDK2 OOTB and provides the device tree to the linux kernel. But its still a new board and some things are not supported in mainline linux yet.
If you are searching for more powerful enterprise hardware, AmpereOne SoCs have ARM SR certification. You can just use any modern linux distro uefi generic aarch64 iso and it will boot.
You need to compile a device tree for every single device you want to support individually, whereas x86 has ACPI to avoid that mess. ACPI is its own mess, yes. And UBoot is great. But it isn't a standalone replacement for a unified firmware interface/"BIOS"/whatever.
It's basically the same solution just in a different format. Device tree specifies device types while ACPI specifies the bytecode to interact with them, but the idea behind both is the same: the computer firmware tells the OS how to interact with it. It's been a slight success in both forms but not nearly as good as you'd hope it to be. The real problem is that nobody's testing all the firmwares and OSes for compliance so lots of devices ship incorrect data in firmware and then the OS has to patch it anyway.
Also uboot is firmware, there's no lower layer it runs on so of course it has to include the device tree. Or in practice, like most vendors, you just put the device tree in the kernel because you know your kernel runs on one specific device model anyway and then you can just edit it when you discover why it's wrong, instead of doing a weird dynamic patching thing.
Uboot contains a device tree which may or may not be in sync with your kernel device tree. Recent uboot supports efi which then muddies the water more.
When vendors ship a specific kernel, you are unlikely to get security updates in a timely fashion, if ever.
Well, for one, the dtbs don't belong with the shipped kernel. If a dtb exists, it should be shipped on the hardware (perhaps as part of firmware.) Right now, there is an intricate dance in some arm setups where:
The installed kernel has 200+ dtbs shipped with it and the boot loader has to be configured by some non-standard userspace glue to detect the correct dtb before rebooting. This glue doesn't exist everywhere and can be ad-hoc per-board or completely non-existent. IMHO, this leads to folks just not updating kernels.
One nice thing (in theory) about a dtb is that there is no code. Of course, there doesn't seem to be an established standard for finding that data so we are back to relying on specialized boot configuration and code anyway.
One place this all becomes glaringly bad is if you take an SD card and move it from one arm64 node to another; There is a good chance it won't boot. It's no wonder there are so many board-specific OS-images floating around instead of having arm64 installers that just work.
Also, a FDT is useless to most OS and remains primarily a Linux concept that has bled into other spheres (like U-Boot) so why would a manufacturer include it?
So ... what should we actually have? A standard on arm that doesn't depend on the triple of which (OS,board,bootloader) you are running. We should be able to just build an arm64 kernel (BSD/Linux/Windows/whatever...) and have a good chance that the thing just works. If that's done via UEFI, then so be it.
IMHO, given (waves hands) the current state of arm64 boards, arm64 support for Linux should look like:
1) Load a board-specific firmware to provide UEFI via EDK2/U-Boot/custom
* This is likely on the board-manufacturer to provide and should be pre-loaded.
On most devices that aren't PCs, there is no separate firmware - the firmware is part of the software. The boot ROM is just loading a sector and jumping to it. You may implement UEFI as your second or third boot stage if you want to, but it's your responsibility.
You wouldn't want the boot ROM to implement UEFI. It would have many unpatchable bugs and different ones on every device revision. Better to put the UEFI where you can patch it. For instance on a Pinephone booting from SD card, the firmware is on the SD card. Moving the SD card to a different device is putting the wrong firmware on that device, that's why it doesn't boot.
And then once you're shipping your own UEFI impl and shipping a kernel that runs inside UEFI, as part of the same SD card image, the next obvious step is to wonder why you can't short circuit those two layers and run the kernel directly on the hardware.
Yup. There is no reason it has to be a ROM though. It can easily be a small flash device sitting on spi or something. Firmware sitting on an SD card is annoying for all the reasons already stated.
It really depends on the shape of the tests and the shape of the language. Eg: Untyped languages often have tests that effectively implement a type system as software grows and the developer count grows. That seems like a waste…
Writing a good test or good set of tests does take effort but enforcing 100% coverage often pushes some folks to just run the code in any way possible within the test subsystem.
> Untyped languages often have tests that effectively implement a type system as software grows and the developer count grows. That seems like a waste…
Nicely put. A very verbose type system that is also placed too far away from the definitions indeed
If a platform was open then we could spin up blocklists for known or suspected bots. We created blocklists for bittorrent. We create and manage blocklists for ads. If we had direct control over our social media feeds we would create blocklists for bots too.
Indeed, and zero-knowledge attribute-based proofs - if done genuinely! - could even by bound to a citizen's id and still be anonymous, which would allow: one person -> one voice and solve bot and disinformation traffic.
But it depends, as much of the solutions to our current problems, that things are solved correctly on the root. In this instance, trustworthy government and transparent processes that guarantee zero-knowledge and free, equally, genuine speech and discussions.
That is the classic problem of decentralized networks, if it is big enough there will be spam at which point you will need moderators to sieve it out. But I think AI can also be helpful here instead of having centralized moderators we can have AI (hopefully self-hosted/decentralize) moderate your network graph for bots/spam.
> The current platforms are overrun by them but seemingly only by choice. A truly open platform would be a bot playground.
You seem to be assuming two things. First, that there is an "easy" solution to this which is available as a result of centralization, and second that there isn't a decentralized one.
The first one is pretty hard for a service which is trying to use a gamable algorithm to show you posts from total randos, regardless of centralization.
As an example of the second one, suppose that your feed shows entirely or heavily disproportionately posts/reposts from people you follow and the people they follow, and you can turn off the second one for specific people. Then if you don't follow bots, you don't see bots. Replies show up if either the reader or the original poster follow the reply poster, and by default for the poster of what it's a reply to or if they choose to make it visible to everyone who follows them.
Now bots can show up to post replies, but only one person will see them and they'll be at the end of the list and marked as someone they have no connection with. On top of that, the user's client can do any kind of algorithmic bot detection they want.
There's also a huge asymmetry between what clients know about each other and what the platforms know about the clients. Bot detection is only really feasible by the platforms.
At which point being unable to solve it because it's uneconomical is a form of being unable to solve it, and the centralized system forfeits the alleged advantage.
Sometimes the problem doesn’t get solved because it is lucrative to not solve it… not because it is too hard/costly to solve. Ie: some platforms don’t internally classify spam/bots/corruption/scams/etc as a problem. Often, the right amount of it increases engagement… and thus the perverse incentive perpetuates or amplifies the problem.
When I first came into the tech space, I found myself with quad copters buzzing around my workspace. I had the intention of hacking the signals around me to dissuade folks from flying around my head while sitting at my desk. After walking into a radio shop, looking for a few key items, I chatted for a few minutes with the clerk. He immediately put me into his “you’re a jammer” box and was uninterested in any further conversation. He wasn’t wrong, but it’s ironic given that I was effectively counter-jamming to get work done… and maybe have a little fun hacking at the same time. Point being: some communities have such rigid rules around what a “good citizen” encompasses that they get lost in their own world.
I find myself more on the altruistic side, despite being far closer to a “computer hacker” than a ham.
If you were going to be jamming quadcopters, you were likely jamming one of 900mhz, 2.4ghz, or 5ghz at the time.
Had you done that, you likely would have shut down most wifi in the nearby vacinity, including office networks, credit card machines, wifi cameras, implanted bluetooth heart monitors, baby monitors, and many other devices.
My methodology was not going to be a broad spectrum jamming device. I can see why you might hop onto that notion given my extremely abbreviated description. The signals I would have emitted would have been in line with existing analog signals… in a controlled environment. I’m not an RF guy but I’m also not ham-fisted, if you’ll excuse the pun :)
To be fair most indoor drones (tiny whoops) have ducts/guards on their props, still incredibly rude though. Personally I'd have "jammed" them with a tennis racket.
You would be breaking multiple federal laws (FCC and FAA) by jamming a drone. He wasn't interested because knowingly helping you could get his business shut down.
You still need at least one IPv4 address somewhere if you want to send ICMP back, yes. (Typically a loopback, i.e., something not connected to a specific interface. Routers use loopback interfaces for rather different purposes than a Linux workstation.) But you don't need to set up an IPv4 address on every interface, so you don't need a linknet plan.
You can also forego the IPv4 addresses entirely, but then traceroute (and presumably also stuff like Path MTU Discovery; have consistent MTUs!) won't work. traceroute is often broken for entirely different reasons, though.
It's amazing how easy it is to lie with numbers. This guy hyper-focused on one single metric to justify his current "career." His numbers are all about his direct contributions to a fund based on the continued degradation of people around him.
No, you aren't a quant. You are a drug dealer with an education.
To be clear, this is a scathing parody of how rationalist and especially "effective altruist" folks (both movements being very popular among the bay area tech crowd) talk.
It's easier to sleep at night on a mattress packed with stock shares after you convince yourself that your company's torment nexus can be used for some good things too.
reply