2,490 karma · joined December 13, 2022
Now, let's just hope the local cyclists don't adopt the same combative attitude as, say, those in Amsterdam, or the many, many remaining motorists on La Periferie...
Not, 'anyone with an RasPi can do it', but definitely 'you can find someone who will host you.'
And yes, the 'powers that be' definitely conspire against this scenario, as they do with federated social media, etc. etc., but that's not a reason to give up!
-If you ever encounter a situation where "well, this volume might contain valuable data" is a thing, try to make a forensically-sound copy first;
-Depending on the exact source media, this might be a very specific process. Don't skip on it, though.
But, once you have an accurate copy of the source media, feel free to run any non-destructive experiments that you'd like. After, of course, publishing the source media for fellow enthousiasts...
And if you're concerned about local storage, the remains of your dirty database pages after the FTL and/or other sector-remapping firmware is done with it are still a concern.
But anyway, apparently someone felt they needed this badly enough to pay for it, so YOLO...
But let me pose a counterfactual: I am the owner of example.nl, and I publish the memoirs of one YA, which the .nl government desperately wants to suppress, for, eh, reasons. The .nl zone requires DNSSEC by default, but I cleverly host my zone on CloudFlare and disable DNSSEC. I also use LetsEncrypt to secure my site, which is only available via HTTPS.
In response, the .nl government instructs all ISPs in the entire EU to route all CloudFlare traffic to its middlebox, and it obtains an SSL certificate in example.nl's name from Diginotar, a notably reputable SSL vendor. It uses all that power to host an alternative version of YA's memoirs.
Which percentage of Internet users will actually see that alternative version? And how many millions of Euros will I be able to collect from the lawsuits afterwards? Bonus question: how much will it cost to replace the melted-down middlebox?
The argument "well, they were able to compromise BGP, but DANE surely would have stopped them" is not only unsupported, but not particularly likely either.
Better question is why this guy is still polling ~50% in the upcoming US presidential election?
Yes, the most likely reason for that being that... it isn't true? The CA ecosystem is fairly resilient against DNS and even BGP hijacks, and simply ignoring innovations like CT is... not persuasive.
> With DANE you can tell the sending mail server that TLS is available
Yeah, or you just refuse to send and receive any email without STARTTLS being in effect. You won't miss much.
The thing about the ST506 interface is that it was really, really simple: you (the disk controller) could seek to a track, the drive would tell you when that was done, then you could select a head, and the drive would tell you when the start of the track passed under that, and then you could read or write bits to the thus-selected cylinder. Again ignoring some finer points like precompensation and read recovery, you really only cared about three drive parameters: the number of tracks, the number of heads (multiplying these gave you the number of cylinders), plus how many bits you could approximately write to each cylinder. If you take a look at the OEM manual for the ST225 (a very popular ST506 drive at the time), the simplicity just jumps at you: https://archive.org/details/seagate-st-225-oem-manual-oct-85
You'll also notice, though, that there is no real mention of 'sectors' anywhere just yet. That's because that wasn't a drive concept, but something managed by the controller, which was responsible for dividing cylinders into sectors holding 512 bytes of user data. That division would mostly be timing-based, but to allow for error detection and recovery, the controller would add some metadata to each sector: typically, a sector number and simple checksum, which was sufficient to perform timing recovery and retry reads as required.
After connecting a new drive to a given controller, the user would therefore need to run a 'low level format', typically by invoking some code in the controller card ROM BIOS, or by running a vendor-supplied utility: this would then go through all cylinders and write the metadata, including all-zero user data, for each sector. For some sectors, this would yield a write fault, and such sectors would be added to a bad sector list, resulting in a drive with a capacity slightly below that advertised. Another parameter used for this low-level format was the 'sector interleave': instead of dividing a cylinder into sectors 1-2-3-4-5 and so on, the controller would do something like 1-100-200-300-400-2-101-201-301-401-3, with the exact numbers depending on the capacity of the drive, obviously, but mostly the speed of the host system. Because PCs were really slow at the time, demanding tasks like 'reading 2 sectors sequentially' would result in a miss on the second sector, meaning having to wait for an entire disk rotation before trying again. By interleaving sectors, this miss could be avoided, greatly improving performance, but also hindering performance in case the selected interleave never or no longer (i.e. after an upgrade) matched the host speed.
Now, let's turn to SpinRite. Its author, Steve Gibson, understood the relationship between disk, controller and BIOS really well, and cleverly improved on the default experience, which only provided destructive low-level formatting and virtually no diagnostics tools. By combining this understanding with a database of drive parameters and controller BIOS details (mainly: what is the address and calling convention of the per-sector read, write and format routines) and a fancy GUI, he provided some real value to early hard drive users.
Initially setting up a drive with SpinRite required no obscure DEBUG commands or utilities, nor guessing of the optimal sector interleave: SpinRite would perform some tests to figure the latter out, and then perform the low-level format, with a progress bar and all, which was unheard of in vendor tooling. Even better, Gibson figured out how to do a non-destructive low-level format, and that was the true SpinRite superpower. Upgraded to a faster system and now stuck with a nonoptimal sector interleave? SpinRite could fix that for you! Did your drive degrade a bit (due to platters/heads getting out of alignment and/or the stepper motor wobbling), SpinRite could literally restore it to factory-fresh performance!
So, fancy GUI and incredibly impressive marketing aside (which Gibson was really good at as well), the basic algorithm that gave SpinRite its legendary reputation was quite simple: invoke the controller BIOS to read all sectors for a few tracks into a ring buffer in RAM (employing as many retries as needed to recover the data if at all possible), re-order those sectors if changing the sector interleave, invoke the controller BIOS low-level format for the first half of these sectors (because you don't want to low-level format too close to data you haven't touched yet!), then write back the data. Rinse, repeat, with some clever handling of bad sectors and saving checkpoint data to an unused disk sector, so restarting the system during a SpinRite run rarily resulted in data loss.
This worked really well for a long time, but broke down completely when disks stopped using ST506 and migrated to "Integrated Drive Electronics" (IDE) interfacing. When using IDE, the responsibility for managing "sectors" moves from the controller to the disk itself. This greatly simplified the controller-to-disk interface, as the former no longer needed to know about track or head counts: instead, the disk simply presented sequential sector numbers, LBAs. LBA-to-physical-sector mapping became a disk vendor responsibility, which it remains to this day in newer interfaces like SATA, SAS and NMVe.
IDE did away with a number of things, including sector interleave, which due to the increase in host speeds was no longer relevant. But it also made it impossible to perform a 'low level format' type operation, since that was now fully a drive responsibility. Of course, the drive firmware might provide equivalent functionalty to the controller, but, especially in the early days of IDE, it definitely didn't do so.
This meant that SpinRite's magic no longer worked on IDE drives. Sure: it could still attempt to read all your data (and with enough retries, that did allow for data recovery in some situations), then write it back (which might trigger a sector re-allocation in the IDE drive, but who knows), but that was about it. This did not stop Gibson from continuing to market it, and 'The Internet' from continuing to embrace it. There were rumors of SpinRite having special backdoor access to IDE controllers and such, but that was basically all nonsense. SpinRite was now `ddrescue` with some `chkdsk` and `smartmontools` thrown in, just with a much nicer user interface.
So, SpinRite started out as an extremely useful tool that was worth its money, then degraded to a no-longer-magical shell of its former self that continued to be over-hyped, often passionately, for about a decade after the point it should have faded into obscurity. There is a lot of hazy discussion around these facts, but simply by looking at how the underlying tech evolved, the picture becomes pretty clear...
I mean, it explains a lot, but still... you're recruited using industry-leading practices out of an overflowing pool of abundant talent... and this is what you make of it? As the kids say: SMH!
The approach that Google appears to have taken, which is to assume that the top-ranked part of its current search index is a sensible knowledge base, may have been true some years ago, but definitely isn't now: for whatever reasons, it's now 33% spam, 33% clickbait/propaganda, with the rest being equally divided between what could be called "truths" and miscellaneous detritus.
To me, it seems that returning to the concept that search results should at least reflect a broad consensus of what is true is a necessary first step for Google. As part of that, learning to flag obvious trolling, clickbait and bad-faith content is paramount. And then, maybe then, they can start touting their LLM benefits. But until the realities of the Internet are taken into account (i.e.: it's 80% spam!), any "we offer automated answers!" play is doomed.
Simply including R&D costs, imagined or otherwise, in COGS seems... fraudulent?
Yeah, well, maybe?
"Democratic presidential candidate Joe Biden said he would remove Donald Trump’s tariffs on imports from China, which are taxes on U.S. consumers and companies. An aide later asserted the former vice president would reevaluate the tariffs upon taking office."
Because if you're counting on Trump to save you, I've got some possibly sobering news: https://www.reuters.com/world/us/trump-says-us-china-tariffs...
Sure, batteries are more expensive than gas tanks, but...
I'd pay a monthly recurring EU$ 0(.|,)99 for that!
Other than "yeah, Hertz has really lost the plot" and (with a nod to lobste.rs) "Hacker News is not customer support for your car rental company", there doesn't seem that much to discuss here?
(And for the record: Sixt [a major-ish car rental company] in .eu requires EVs to be returned with at least 80% charge these days, and will have an add-on fee otherwise [so: take a picture of the dashboard upon return!]. Not, like US$277, but a fee nonetheless)
(And, in case you're wondering why The Netherlands imports so much LNG: that's where the terminals are...)
And even though the Apple press release does not even mention memory capacity, I can guarantee you that it will be even less than that on an iPad (simply because RAM is very battery-hungry and most consumers won't care).
So, therefore my remark: it will be interesting to see how this chipset lands in MacBooks.
No, when using wording like "outrageously powerful", that's exactly the comparison you elicit.
I'd be fine with "best in class" or even "unbeatable performance per Watt", but I can absolutely guarantee you that an iPad does not outperform any current popular-with-the-ML-crowd GPUs...
Yeah, well, I'm an enthusiastic M3 user, and I'm sure the new AI capabilities are nice, but hyperbole like this is just asking for snark like "my RTX4090 would like a word".
Other than that: looking forward to when/how this chipset will be available in Macbooks!
-The SN2010 retailed for about 10K (Euro/Dollars)
-It has never been truly available, as in: you could go somewhere, order it, and expect it to turn up in 2-3 days
-Even though small, these units tend to be loud, with at least 2 tiny fans making a lot of high-pitched noise
But the most salient point is that, even with "Linux on a router/switch", there's no guarantee that you'll get decent performance, as that entirely depends on how well the kernel understands the (proprietary) onboard chipset, which usually means that you're squarely in "well, here's this blob that works on certain kernel versions, and good luck with that!" territory.
And, looking at the increasingly bad results from "industry leaders" like GPT-4 (which, at least for coding tasks, now seems to be resigned to generating "insert boilerplate code here" comments, which is as hilarious as it is useless), it might very well be correct as well.
The more an AI approaches the human mind, the lazier, and therefore less useful, it gets?
Turning the front skis (which have a range of, maybe, 20 degrees, not sure, never used them!) is discouraged, and probably doesn't do much, except in emergencies. Like braking!
And yeah, these things weigh around 200kgs (450 lbs), before occupants.