6,226 karma · joined February 13, 2014
I freqently think that my parents best parenting choice was the choice to not have a TV in our house when I was growing up. It both saved them money but removed a very common time wasting/entertainment outlet. My own kids went from playing with legos, creating art, or messing with science kits to playing on their phones as soon as they were given that choice. And i'm still of the opinion that providing that choice was a big mistake, they are experts on the latest social media fad, and quite ignorant about things I wish they would have learned.
So, yes enviroment matters, some kids will hack even when given an xbox and a pile of games, but I think more of them will try it if they aren't given those choices.
edit: I see immediately below while I was composing this, someone mentioned pararchive..
I think this is a mischaracterization of TSO. TSO only dictates the store ordering to other entities in the system, the individual cores are fully capable of using the results of stores that are not yet visible for their own OoO purposes as long as the dataflow dependencies are correctly solved. The complexities of the read/write bypassing is simply to clarify correct program order.
And this is why the TSO/non TSO mode on something like the apple cores doesn't seem to make a huge difference, particularly if one assumes that the core is aggressively optimized for the arm memory model, and the TSO buffering/ordering is not a critical optimization point.
Put another way, a core designed to track store ordering utilizing some kind of writeback merging is going to be fully capable of executing just as aggressively OoO and holding back or buffering the visibility of completed stores until earlier stores complete. In fact for multithreaded lock-free code the lack of explicit write fencing is likely a performance gain for very carefully optimized code in most cases. A core which can pipeline and execute multiple outstanding store fences is going to look very similar to one that implements TSO.
Basically the installers should be replacing the existing certs and keys, with distro supplied ones which are maintained along with global DBX entries by the distro itself, with a distro supplied KEK/etc where the private keys are stored in a high security environment not available to most users.
Its really the kind of project the linux foundation should be sponsoring so the infra could be shared cross distro.
The distro installer should, if it detects setup mode, automatically be asking the user if they wish to replace the all the existing keys and enroll distro supplied certs, keys and dbx entries. Except none of the distros have this infrastructure built, outside of their dependence on Microsoft.
And no, none of this is needed if all you want is to be able to self sign a kernel/etc because its possible to install a MOK key to shim, but that isn't the point, the point is that the vast majority of linux users aren't setup to protect a cert/key chain from an attacker. Which is the entire reason for secure boot. If your attacker is sophisticated enough they will be stealing the signing keys from your machine/org and signing their own updates. Which is why MOK and self signing is a mistake for ~100% of Linux users.
So today a decade+ later there still isn't a standard way to automatically enroll a linux distribution's keys during initial install in any of the distributions (AFAIK).
First, its a ~30 min flight to Houston, and a ~40 min flight to Dallas, two of the largest and busiest hub airports in the USA. So, a massive amount of american/united Austin traffic is Austin->IAH/DFW->destination if your not flying southwest with a direct route. Yes, there are a number of direct routes to other places, particularly large hubs (DEN/ATL/JFK/etc) but its like once a day or every other day for non hub airports.
But that pattern is doubly reinforced through local decisions which have resulted in ABIA being the number #1 airport in the USA for flights per gate.
AKA, by gate count it has the highest utilization of any airport in the USA, and this is the result of the anti-growth politics for the past 40+ years, that did things like move the airport from Mueller, to ABIA while initially planning on having the same number of gates as Mueller, and only relenting and adding 4 (IIRC) more. And keep in mind that Mueller was frequently like going to a crowded standing room only bar. And not only was ABIA undersized but it wasn't designed for serious expansion. And really, there wasn't any excuse when one looks at any airport designed in the past half century its obvious where the terminal expansion is planned (ex:DFW) with the better designed airports like TPA/MCO using a hub and spoke model. Instead what Austin is going to get is an ad-hoc expansions which will result in Heathrow levels of suck (and its already that way for the south terminal, where one has to leave the airport, drive for 10 mins and then re-enter).
Right, and this should be the single deciding factor for most system programming and core infrastructure development. One doesn't throw away 20+-year-old battle-tested code simply because it's grown ugly bug fixes for edge conditions no one wants to worry about. The idea that it's possible to throw away, say 30-year-old font rendering code and replace it without revisiting a lot of the problems along the way is peak hubris.
And the same goes for choosing and building internal IT systems, KISS should rule those choices because each layer adds additional code, additional updating, etc. Monolithic general-purpose software is not only a waste of resources (having software that 9/10th is just taking up disk/memory/cache space because only 10% of its features are used), but it's a maintenance and security nightmare.
This is the problem with much of the open-source world, too. Having 20 different Linux filesystem drivers or whatever is just adding code that will contain bugs, exploits, and a monthly kernel update containing 80 KLOC of changes is just asking for problems. Faster processes, updates, and development velocity in projects that were "solved" decades ago are just a playground for bad actors.
So, to go back to Andrew Tanenbaum and many others, no one in their right mind should be writing or using OSs and software that aren't built from first principles with clearly defined modularity and security boundaries. A disk driver update should be 100% separate and compatible with not just the latest OS kernel but ones from 10+ years ago. A database update shouldn't require the latest version of python "just because".
Most software is garbage quality written by a bunch of people who are all convinced they are better than their peers. And yet another code review, or CI loop, isn't going to solve this, although it might stop a maintainer from throwing poorly tested code over the fence instead of subjecting it to the same levels of scrutiny they give 3rd party contributors.
Most firmware systems don't enable interrupts, support paging, SMP, or many other things, for a long list of reasons, while at the same time, in order to enable a full Linux environment, ExitBootServices must be called, which is going to make a mess anytime the booting kernel isn't the right one. Kexec breaks a fair amount of the time if the target kernel isn't exactly what was already booted (ex, see kdump failures). Nevermind if the target OS isn't linux.
And for what? So /boot can stick around? A legacy partition left over from the days of BIOS/MBR like systems that have to have a small partition at the beginning of the disk, formatted with something that supports linux file permissions?
No, the right solution is to just place the kernel(s), and a small signed initrd (s) in the ESP, and nothing else besides a boot selector, like say systemd-boot to allow the user to select the correct kernel/OS, and optionally edit debug/etc options. Then, when the correct kernel is booted, it can bring up the network, filesystem, and whatever is needed.
That solves an endless list of Linux and firmware interaction problems that Grub currently solves, without all the file system, network code, etc., that one finds in Grub, which mainly duplicates the functionality already provided by UEFI.
The problem with this solution is that it doesn't work on systems that aren't UEFI, to which I might suggest that those systems (cough, legacy IBM junk, or hyperscalers still using BIOS boot after it has been deprecated everywhere else) have either uboot-uefi or edk2 ported so they can conform to modern boot standards.
But, did no one stop and question whether a TPM should have been on a dedicated block that couldn't be reprogrammed rather than assuming there wouldn't be bugs or whatever in the GPIO pin muxing? Never mind all the additional complexity of assuming page permissions access/etc to shared purpose MMIO regions?
So, IMHO this starts as a hardware bug.
Also SCSI tends to be easy to convert if one knows the drive connector/type, and is willing to chain a couple adapters. I'm sure that is the case here too, the 2.5" scsi drives were a form of SCA connectors IIRC, SCSI adapters exist for almost anything to anything as long as the single ended vs differential rules are followed, newer ultra differential adapters could usually fall back to 8 bit single ended allowing them to drive just about everything. The problem is going to be finding an OS/etc that can real the old mac filesystems although I'm guessing one of the utilities to read raw images (of which i'm failing to remember the ones Ive used in the past) could probably read/write the raw disk image.
The state tax system heavily penalizes anyone who can't pretend to be a farmer, so you will have people with 'hobby' farms that are valued 3x+ outside of the urban areas who are playing 1/2 or less in taxes than someone with a modest home in the suburbs. Then these areas are then heavily subsidized with schooling, roads, electric and internet services. Which is a feedback loop where those counties won't raise taxes because then they get less funding transfers. Until the recent reset of the tax exemptions its was quite likely most people in the state would have been paying the same or less taxes in California.
The state hates public parks, so the per capita acreage is such that the parks are both way over utilized and nearly impossible to use due to the overwhelming demand for camping/etc on the weekends.
Then one combines the many state inflicted problems with Austin's issues. Like the fact that there is a very strong anti growth lobby the ties everything up in courts. For example that the main interstate highway going through town has been functionality obsolete for 30+ years and any attempts to fix it are stymied at every turn. Then Austin will convert decades old overcapacity four lane roads into two lanes with a rarely utilized bike lane. Or while Austin is unusual that it actually has a lot of in town public land (BCP/etc) the vast majority is closed to the public and any appropriated money is used to fence it off and post no trespassing signs, rather than providing recreational or nature oriented opportunities. And again the anti growth people formed a coalition with the green heads to slice the western part of the city up into sections requiring people who live in those areas to drive miles and miles out of their way to get around the preserves which combine with the lake to form long barriers to direct traffic flow.
Which goes to the general incompetence/fear the city has about road construction, light timing, light rail construction, etc. Leaving bonded projects never being started because they either spend all the money on smaller included projects and never getting to the main one, or waiting a decade+ to break ground and discovering that the project is now 2x-8x the original estimates.
The air quality is some of the worst in the country for $REASONS.
I could go on, but its a _long_ list of issues.
And that is part of the fun of RDP, it has an immense number of different ways of accomplishing the end goal, and newer methods were being added to compensate for the way applications themselves were being written while the older ones remained. It was a long road of dealing with edge cases, with certain applications not rendering properly.
AKA, use a 3rd party library to draw all the GUI widgets and windows didn't have any alternative but to come up with a better way to compress and send those updates. And the last time I ran an RDP client to Windows, this stuff was still visible; older win32 applications were fast/responsive, and things like Firefox would just chug every time it hit a web page that was doing any kind of dynamic content (think scrolling an ad).
But IMHO, no one should be running a NAS without ECC at this point. It's on the "my RAID doesn't scrub the disks" level; it's just begging for silent disk corruption that propagates its way through backups and is impossible to fix with software solutions.
While true for things like firefox, and GUI libs that think they know better than the host, its not ideal, and entirely dependent on the language/toolkit being used. And it's a side effect of X being too low level and not having a standard widget toolkit as one gets on Windows/mac. On those platforms, it's not just the widgets but file open dialogs provided by the OS, skinned consistently across applications, and things like global keyboard shortcuts (ex, copy/paste) tend to work close to 100% of the time.
If one goes back to the win3.x/macos7/etc timeframe it was almost unheard of for applications not to follow system wide color themes. WHich is why "dark mode" 1995 worked more reliably than it does on any platforms today. Today, doing something like inverting to a "dark" theme is suddenly something that each application hacks in, and when the OS provides a theme option, the applications frequently don't follow it correctly/etc.
Much of the reason RDP and WebGL work so well is that they send the raw command stream/assets to the rendering side rather than continuously sending a stream of compressed frame buffer data. RDP, for example, can send the raw video stream being played, or recompress it, and send it rather than trying to render it to the screen and then recompress the resulting output, which is what you get with something like VNC. Thats why its completly possible to stream video over RDP on links that choke up pretty much everything else.
For an incredibly wide range of things, high level GUI command streams are going to be significantly less data intensive than the resulting rendered and compressed video stream. AKA the GUI command stream is itself an applicaiton specific compresion algorithm. A draw line command can affect tens of thousands of pixels around the line due to antialiasing, and that won't ever compress as well as the drawing (x,y,brush). So while sending a bunch of textures, shaders, and the like might be a huge initial overhead, its going to quickly pay for itself over the lifetime as used in something like a game/etc, particularly at high resolution and refresh rates.
Never mind, of course, the overhead of doing a bunch of local rendering, compressing it, sending it over the wire, and doing video playback. If it weren't for hardware video encoding/decoding, it would essentially be a case of pegged CPUs on both sides just doing graphical updates.
This may just be one of the issues with Wayland compositing; over time, I've become more convinced that the loss of standard GUI widgets and a serializable drawing stream might be a huge mistake.
The latency numbers have barely moved in a decade. And swap in operations are 100% a latency test, best reflected by qd=1 random 4k read (well 16k on a mac, but the point remains since the IOP numbers will be roughtly the same with a 4x larger bandwidth at 16k). It's rare to see an SSD that can even do 100MB/sec qd1 random read, and the numbers largely seem to be going backward as the number of bits being packed into each cell increases (ex MLC->QLC) on many products.
Bandwidth has always been easy, I had spinning RAID arrays that were faster than your average SSD 15 years ago if the only measure is bandwidth. This is why the xpoint disks were a big deal. 2-3x faster QD1 iops numbers.
AKA, a lot of this is the result of generations of poor education, an education system that is strongly biased propaganda based on provably wrong economic models that tell k-12th graders that the best and only choice is the one where the free market runs roughshod over anyone who can't afford the rent, etc because that's simply "capitalism" and all the other choices are worse.
Put another way, I don't think i've ever seen a customer walk from a product because it wasn't released on a cadence, in fact many aren't actually happy about upgrades unless they are fixing a problem they have requested. And sales/POC cycles are such that frequently the customer may not actually have an alternative solution, or if they do, the chances they will switch to your product simply because you have X this year instead of next year isn't something that hinges on small factors that can be done by the engineering team in short cycles. You win because the product is better/etc and that doesn't happen overnight.
So, stressing and working endless 80 hour weeks likely is going to have the opposite effect and creates a low quality product that people are trying to get rid of because it keeps breaking.
Whether or not the resulting ranges are encoded in a space saving manner (as this algorithm is doing) or used as input into a BW transform/Huffman/etc sorta depends on the resulting value sequences.
Much of this though should apply the understanding that data being compressed can frequently lead to data specific preprocessing that can significantly increase the compression ratios over generic encoders. Just taking the output of this routine and running it through deflate might yield another couple percent if it were tuned. Or put another way, all the bit prefix/shifting decisions might be redundant for certain cases because the 0's would end up being single bit tokens in a Huffman encoder.
Plus, the server/provider side remains a huge weak point too. And the effort of enrolling/giving the user the initial seed is suspect.
This is why the FIDO/hardware passkeys/etc are so much better because is basically hardware enforced two way public key auth, done correctly there isn't any way to leak the private keys and its hard has hell to MITM. Which is why loss of the hw is so catastrophic. Most every other MFA scheme is just a bit of extra theater.
And of course ebay and archive.org/etc is a source for the old manuals or even kits (I recently saw the SFX-4000 aeronautical lab kit in an old fashioned toy store in town BTW) if you can't be bothered to grab the manual and do a bit of footwork to restore an old kit. But frankly people have to fond of memories for those kits. For example, a good used microscope from a college can be picked up on ebay and some slide + stains for just a few dollars these days and its a far more useful tool that the cheap toy oriented kits. And while I printed and bound a copy of the golden book of chemistry some years ago, one should really read more recent criticisms of that book before handing it to your child (ex; don't go tasting lead based compounds).
The modern equivalent of course are Snap Circuits https://elenco.com/snapcircuits/ but having purchased one of the larger kits for my kids a couple years back I think they suffer from the same basic problem. Sure telling 10 year old me about BJT biasing might have been a bit much, but I really think it should have been included in some kind of side note even if it doesn't sink in the first time.
PS: Actually thinking back on it, these spring board ones are probably better from the perspective that a blown component was easy to replace simply by pulling out the cardboard flipping it over and disconnecting the component from the springs underside.
I see people dumping old jackery, ecoflow, models for 1/3 of retail on craigslist/etc somewhat regularly although those tend to be larger models. Its a bit of a mystery to me why some of them aren't advertised as having UPS functions if they have fast switch times, which many of them do since they don't have physical relays. My old line interactive UPSs are all physical relays which click when they switch over, the assumption is that the energy in the transformer is sufficient to cover the switching time, but of course they do brown out a bit when near their current limits.
I've been doing something similar for quite a while, by default blocking windows machines from having internet access, except for a tiny subset of programs. A dark island with a boat dock if you will.
Turns out its a real PITA with "modern software" much of which can't even install itself without internet access and programs that actually provide self contained installers becoming fewer and fewer.