It blows my mind that this wasn’t more widely publicized over the years. At least this is the first time I’ve seen it, and I learned vim a long time ago. Partly because if it was a choice between weird keys, may as well learn vim.
It blows my mind how many people need directed at the included documentation or config files.
Sheep to slaughter. Before anyone judges me for judging, instructions-included is pretty consistent across disciplines.
I'm not a mechanic but I can figure out routine maintenance/customization.
I'm surprised you, and surely others, arrived at switching editors instead of changing the editor itself. Not in the source or with compilation. The configuration.
I know you say partly, I just doubt there is any perfect editor. All roads lead to configuration.
That was only one of the reasons. The keybindings were the seed of the idea, but as soon I started thinking about what I would like to change, I realized that I also wanted multiple edit buffers and a directory browser. Essentially it's my all-in-one coding environment.
Most non-programmers don't give a shit about their router beyond "the wifi must work". Something completely stateless that can't be broken or messed with actually sounds like something they'd want.
Well, considering that most home users never update their router's firmware, I'm going to go out on a limb and suggest that the majority of applied updates are malicious.
If you did want to go this route, a simple fix would be to have the write enable line gated by a hardware one-shot timer (think like a 555 timer) triggered by a physical button on the front (and the button would also reboot the router).
The firmware update sequence would go like: Router prompts user to update using button -> user presses update button -> router reboots to clear malicious software -> when the router comes back up, the write enable gate remains open for $n minutes (and maybe there's a GPIO that can hold the gate open if it is already open) -> router performs software update.
The problem is that there's pretty much no way to do this without adding a $1-2 to the BOM, and no manufacturer of (pro|con)sumer routers will do that.
Edit: Or do what stacktrust wrote and just have a toggle switch (update/secure).
> Well, considering that most home users never update their router's firmware, I'm going to go out on a limb and suggest that the majority of applied updates are malicious.
Consumer grade routers often have automatic updates these days.
Yeah I have a pretty nice router and inexplicably, random nights, it drops out at 3am for ~3 minutes and then comes back on (and has all the markings of a reboot in terms of the pattern of request failures). I have to assume Synology just decided that nothing's using the internet at 3am
I had no idea that Synology did routers too, but I would assume this would be a configurable time somewhere in the settings. But yes, that sounds like automatic updates to me.
So here's another problem. Going back to the point made earlier in this thread "users don't care much about their routers." The average user opens their router page exceedingly rarely, which is the benefit of automatic updates. I set up my mom's router, and she works in IT (more in project management these days, so she's fallen into being a mostly non-technical user.) And she still texts me every time she needs to get into it to ask me what the password I set up was... once every few years. The downfall of automatic updates is obviously something like the case of the article this discussion is about. But weigh up the costs and benefits, in my opinion, the scale tips more towards automatic updates when you factor in all the critical level vulnerabilities that router OS's have accrued over the years.
Wormable vulnerability in a router is 10x bigger issue in practice than attacks that brick a router. By "in practice" I mean judging by the real world attacks that I know of. Hacked routers are used as residential proxies for criminals, for DDoS attacks, fast flux networks, credential stuffing attacks, and more. Bricking routers is rare (and very loud), that's why it's news on HN.
Many router malware families don't even try to be persistent. Even Mirai - arguably the most famous router botnet - is not persistent [1]. In case the device is rebooted, it just gets infected again in a few minutes.
It's very important that all network connected devices have an update mechanism, working automatically in the background.
[1] At least the original version. After the code leak people were doing all kinds of updates, so there are some variants that try to be persistent in some cases.
I think that’s usually the case: that will be stored in a small 24c or 93c (i2c or SPI) chip that is separate from the firmware that may only handle 1000 flashes and takes a lot longer to flash (often requiring risky and long downtime).
Half of my technical friends haven't changed theirs from the factory defaults. None of my non-technical friends have changed them. A non-representative sample of SSIDs I receive in my apartment gives 9 default ones, and 2 custom ones (plus mine).
plenty of routers in my country (id go on a limb and say the majority) have both written on a sticker, different password for each device generated when the firmware first gets installed, and people NEVER change it.
edit they also come with a QR code you can scan on your phone to connect to the wifi without manually copy the password, so people just put up that qr code somewhere and connecting is easy enough.
> The economies of scale you get by packing people in larger vehicles mostly have to do with the cost of fuel and staffing.
Trains (and train-like options such as metros) are vastly more efficient than cars in number of people moved per unit of time per area used. That might not be a big deal in suburbia, but in dense inner cities it's one of the most important drivers of public transport.
Autonomous vehicles could chain up or drive really close together and achieve similar space efficiency. Also, if you look at a train track. It's mostly empty space with a train passing occasionally. Very different than a well used road. And autonomous vehicles could collaborate to counter any congestion.
What makes trains efficient has more to do with the cost of energy and drivers than anything else. Both of those go away if you have autonomous electrical vehicles.
The New York subway moves 3.2 million people per day. Taxis and ride share options are together good for about 1 million. Mostly non autonomous and polluting of course. If you triple that with autonomous vehicles that use the road smarter, it sounds doable to match what the subway is moving around. And of course people would be using these for point to point traffic and cars would be able to re-route based on traffic as well.
These comparisons are never quite apples-to-apples because the heavy rail line assumes only a few passengers have any luggage and that the entire line is used only for passengers, whereas the capacity rating for a road allows everyone to take large amounts of luggage and freight is always mixed in as well.
You also have to take into account all the other factors that make roads preferable, for example, that rail capacity number assumes perfect utilization. In practice railways often have lots of downtime due to overnight shutdowns, broken signals/trains and labor strikes. None of these affect the roads.
Where can I buy these roads that don't require maintenance ? Cars that never break down ? Road traffic signals that never fail ? For the first I'm asking for a friend as the road outside her front door is currently torn open for a whole month and it sure seems like "Just magically never do that" would have been a better option if you insist it's so easy.
The lines near me have freight on them (I live in a port city, a noticeable fraction of the country's imports and exports go via intermodal containers on trains) and still run like two services to London and two to other big cities per hour. The freight has to fit in between passenger services, that's a policy decision and the US just picked wrong.
One thing I try to do is read stuff from people whose job it is to do stuff. What I read from transportation people is that for dense urban areas cars are inefficient at loading and unloading. And self driving cars are the worst.
My rando observation is the few times something has gone really wrong on BART traffic is bad enough that it'd be better to take the day off. Ditto if a truck overturns on one of the bridges. And the latter happens way more often than the former. Reminds me after the Loma Prieta earthquake the bay bridge was out for a month but BART was running 12 hours later.
By “transportation people” do you mean rail fans or avid cyclists? It’s an easy mistake to make - civil engineers with a more favorable attitude to cars (or even to rail) are more likely to be employed and therefore relatively quiet than rail fans or cyclists, who spend their time doing advocacy.
Roads can tolerate a lot of damage and be repaired whilst still in use (at less capacity). Capacity might fall but repairs are signalled in advance and people can plan around them, traffic will flow anyway.
In places with big rail networks you're going to hear "I didn't make it into work this morning because of signal failures" really often. And when railways are repaired they will be totally closed for months. They're just way more brittle and unable to degrade gracefully.
You are moving the goalposts here. However if you want to compare mixed freight and passenger lines then rail equals many, many lanes.
Plenty of rail cars have room for luggage too or even baggage cars. Usually we are talking about people going to/from work however hence most people are not carrying lots.
Are you really saying your roads don't have shutdowns for maintenance? Or other problems? Also it is pretty rare for either roads nor railways to be fully utilised overnight. Also note that plenty of rail systems do run overnight.
Rail can support freight of course and complements trucks very well. Rapid transit can’t really support freight if it wants to operate at any reasonable frequency - you just can’t load any real quantity of freight in a few minutes. Even baggage is stretching it a lot of the time on busy lines. And the slow acceleration times and length of freight trains severely conflicts with the needs of passenger rail. Therefore, freight and passenger rail need to be separated for either to perform well. On the other hand, cars and trucks are a lot more similar in performance and size, so they can share the same roads just fine - it’s only an issue if the road is completely choked with trucks.
Well, they are - you can move more people with a sidewalk :P. That being said, obviously most people aren't going to walk much more than maybe a km before looking for alternatives.
Usually the comparison comes up in cities where throughput is the limiting factor, and cars end up moving at near-walking pace anyway.
Urban train tracks see more than occasional traffic, whatever that means. And those trains often carry hundreds of people. Meanwhile, a well used road is well used by huge vehicles carrying 1.2 pax on average.
And energy isn't free. If we had any intention of becoming net zero, electricity prices had better increase. And driving around 2t empty weight isn't the way to get there.
Incidentally, a trip that's less than 1 kWh (so, less than 6 km) is a trip that could easily be made on foot or by bike.
Roads already occupy massive fractions of most cities. Making cars drive closer together or collaborate will make roads environments more hostile to pedestrians than they already are - and arguably in many places we shouldn't even really have private drivers aside from business users on the roads, given the massively disproportionate space they require vs a pedestrian or PT vehicle.
A train line has 10x the capacity of a single lane of road. Even if trains are only coming every few minutes, its impossible to compete with a train carrying 1k people with cars. Perhaps reasonably loaded busses would be comparable or better, but that's not the argument you're making.
Trains are financially efficient because of cost of energy and drivers (and, arguably, roads + cars move much of the expense to the public, where as everything related to the train is on the operator's balance sheet), but they are also very space efficient, compared to roads + cars.
The point of bullshit charges is often to obscure total cost upfront. We are absolutely rotten with them in the UK. Not sure the US is better but I think they are really anticompetitive because they create a cost to discovering the true cost of goods. I have a personal policy of not buying if I discover stupid charges at the end of a sales pipeline but it’s sometimes incredibly inconvenient.
Crop dusting and spraying by tractors are in the same market. Everyone but the smallest farmers makes the comparison on whether crop dusting or using tractors is cheaper (including factors like application efficiency and crop loss from tractor tracks).
There's plenty of talented developers out there that are currently working in another language, but could relatively quickly learn the required Rust skills to go work on such a project. Domain knowledge (codecs, video/audio processing, etc) is probably a bigger problem.
Note that for most systems this transition already happened with the transition to 64-bit architectures, in the 2000s. It's only 32-bit architectures to which the current transition applies. Debian couldn't have transitioned them 20 years ago, as kernel support for 64-bit time_t on a 32-bit architecture is fairly recent (Linux 5.6 in 2020).
I remember OpenBSD working on this about 10 years ago.
Also, strictly speaking transitioning with the CPU architecture is not enough -- having kernel APIs and ABIs have 64-bit time_t is not the only place it needs to change. Notably, it has to change in the filesystem too. And at that point millions of people will have on-disk structures with 32bit timestamps, so it needs to transition in a somewhat back compatible way.
> ^ surprised by this line. guess it also impacts lib32 packages on amd64
The reason for this is that in Debian, package name and ABI are coupled, as that allows you to coinstall multiple versions of libraries with different ABIs. This transition changes the ABI on 32-bit architectures, so the package name of impacted packages also has to change (they get a "t64" suffix). While it's technically possible to have different package names on different architectures, that's a PITA to deal with, so they opted to also change the package names on 64-bit architectures, where it's not strictly required.
Business aviation (i.e. "private jets") has exactly the type of customer for whom being able to make phone calls in-air is a thing where cost is secondary.
Gogo even pivoted to that market entirely [1], with the commercial segment now part of Intelsat.
reply