Posts by RichardBarrell 92 posts • joined 11 Oct 2010
I think pattern matching is easy to underestimate if you haven't used it. When people first hear about it, their initial reaction is often "slightly nicer switch statement, what's the big deal?"
The fact that sum types make the type system way more useful isn't obvious at first glance. You have to either think about it really really hard, or have someone show you one of the "make illegal states unrepresentable" essays.
Mm. Running vi or emacs on the remote machine over ssh *does* have high UI latency during text editing. You can almost compensate for it in vi by typing ahead, but from experience it's not a fun or reliable experience.
Running VSCode in a web browser is more like using emacs tramp-mode. Edit locally, save remotely. I assume there's a vim plugin somewhere with similar functionality.
It splits state between the local and remote processes. The latency only kicks in on save, not during ordinary text editing. Save doesn't block the UI either.
If you're in a "save, build, deploy to remote environment, test, edit" cycle then having the editor save directly to the remove environment can be a net time saving. This is my experience with AWS's equivalent thing (which I think is also based on VSCode).
Using the IP address for authentication and authorization like that seems like a slightly hazardous plan to me. Ignoring the idea of deliberately spoofing IP addresses, there's the fact that CGNAT is deployed in the wild. This means we already see public IP addresses shared between different people as a matter of course. We should expect the use of CGNAT will be expanding every year in the future as IPv4 address space gets more expensive.
> They did contribute code fixes back, and they didn't keep any enhancements to themselves
FWIW, I've seen with my own eyes redacted stack frames in the error logs when AWS's hosted ES crashed on me. AWS's ES fork is certainly not open and they are very definitely not contributing everything back upstream.
When I say "crashed", I mean in spectacular fashion. AWS's ES is incredibly unreliable in my experience. I would not voluntarily use it in production. When I looked at the support forums, AWS had for more than half a year had a known broken build of the cluster software set as the default to be deployed when creating a new ES cluster. No idea if they even fixed it since. Amazon Elasticsearch Service is radioactive poo and you should not touch it. Run away, do not walk, run.
I'm a tad sympathetic to Elastic here because on their public forums they've been getting plagued with requests for help caused by the bugs in AWS's closed fork.
Intel has historically very rarely offered refunds or recalls for faulty hardware. They refused to offer refunds for the previous TSX faults in Haswell chips. I *think* the Pentium FDIV bug was the last time they offered replacements for faulty chips. There have been a lot of errata in a lot of Intel CPUs since then.
In theory, a lot of things could possibly have used it. Many things that use multiple cores for parallelism, anything that vaguely resembles a database. Don't think "TSX competes with SQL begin/commit/rollback". Instead think "TSX competes with LOCK CMPXCHG & friends for in-memory data structures".
For actual applications, I can't find much online. Apparently a PS3 emulator called RPCS3 used it, Oracle DB, SAP HANA, some HPC workloads.
You could also use it to make a faster version of mincore(), but that function is kind of useless anyway. ;)
It feels like a shame because limited hardware transactional memory was one of the more interesting recent-ish developments in CPUs.
Some.
The thing where I can press the windows+arrow keys to do things like maximise a window or half-maximise a window onto the left or right side of the current screen is pretty nice. :)
The start menu having built in substring text search over Start Menu shortcuts (ONLY!!!) was briefly really good. Unfortunately Microsoft subsequently ruined it by adding in web search too in the same place. :(
The start menu recognising when you type in simple arithmetic expressions and showing you the answer is really good. Unfortunately it only sometimes works, while the other times it does a bing search instead. :/
AKV is a little pricey and slow. Something on the order of 0.2p per 1000 reads and 10ms per read, I think.
The result of that is that it's often worthwhile to cache values you get from AKV (and possibly periodically re-fetch them in the background).
If you're caching the data from AKV for a while, it's pretty plausible that you might not ever notice five minute drops.
Simplifying a bit, JPEG has three important stages:
1. DCT (almost lossless)
2. quantisation (very lossy: this step is where you discard information on purpose to make the file smaller)
3. entropy coding (this step is lossless)
The entropy coding algorithms in JPEG aren't state-of-the-art, so if you swap out just that step for a more up-to-date alternative, you can get a somewhat smaller file with exactly the same meaning.
FWIW im for anyone who finds themselve in the situation where `rm *.foo` fails because the argument list created from that glob is too long:
find . -maxdepth 1 -name "*.foo" -exec rm {} +
is (barring syntax errors, apologies if I left typos in that) often able to make progress anyway because it passes smallish batches of arguments at a time.
Or:
find . -maxdepth 1 -name "*.foo" -delete
is a little quicker on systems that have that flag. Be sure that the delete or exec flag goes *last*.
FWIW, advice given for this specific RCE was roughly "if it's online and unpatched, assume it's already compromised" and that was a few days ago. I assume that you probably don't have the admin console exposed to the internet, though. If you did, you'd want to be planning to do more than just apply patches.
On a lighter note: wow, 10GB of RAM to apply patches is kind of impressive. I wonder what they must be doing with it? *Nice* binary patching utilities are supposed to normally only eat memory proportional to the sum of the old and new file sizes. There aren't any files bigger than about 4GB being patched, are there?
Hm. I hope this works out for them. It sounds like it might have a reasonable shot at being a steady revenue source.
Usage based pricing is straightforward and makes sense. The free limits mentioned here are high enough that I couldn't plausibly see myself as a developer hitting them at any point. "docker pull" takes a minimum of 5 minutes for me, so no way am I managing to do that 100x in the space of 360 minutes.
A fairer comparison would be the comments on a new GNOME or KDE release. All the changes people are likely to dislike happen way further up the stack. Perhaps if MS did Windows releases that touched only the kernel and a few bits of libc, you'd see similar levels of "sounds fine, nothing to worry about".
When I was a young warthog (when heeee was a young warthoooooooog) they used to have us all sit in a large room and have a human being "watch" us (mostly by the expedient method known as "reading the newspaper").
I can't think of any reason bar stupidity or greed why you shouldn't be able to just pay a human to do the same invigilation job that the AI is failing at. Put 30 cam feeds side by side on the invigilator's screen, have them sit down in front of a wall of faces while they sit and read the newspaper. Job done. You don't even need the invigilators to be able to see all cameras at any given time; if they're flicking through cameras at random, and the exam-takers know this, and the exam-takers don't know whether or not they're being watched at any given moment, then that's just as scary as being constantly watched. Just ask Michael Foucault.
Or... better method... say "fuck it" to exams and grade coursework instead, which is arguably a better approach anyway.
Ah! "What will we call it if everybody goes back to on-prem" is an interesting question. Think about the attributes here:
- it's the same kind of stuff: you still have storage, compute, managed platforms
- it's also going to still be fluid, because you'll want to be able to manage shifting workload around the entire fleet of boxes to be cost-competitive
- you'll know exactly where it is at any time. the physical location will be much less nebulous
So. Same substance as a cloud, still fluid, location is known.
I think we should call it a "puddle".
Turning them off unilaterally sounds like a very bad idea, no matter how much advance warning is given. It would be a blow to AWS's credibility. Like any platform, customers depend on it to not break their stuff.
"Don't break your customer's stuff" is just about the first commandment for running a successful platform. (If not, it's definitely top 3.) Every time you break their stuff, customers will do a cost benefit analysis on moving onto one of your competitors instead of moving onto version n+1 of your platform. If you get a rep for doing it often, moving to your platform becomes unattractive.
IMO the obviously correct thing to do is just suck it up and deal with the technical challenges, indefinitely. Charge more per request to the path style endpoints. Those customers will have a financial incentive and you can aggressively market to them "heyyyy you can reduce your AWS bill right now simply by changing how you use URLs." They'll get to it when the savings outweigh the risk & expense.
"No backlight" is kind of a weird complaint to hear about a Das Keyboard. The whole gimmick of the original Das Keyboard was that it came without any glyphs on the keys so you could show off that you're a touch-typist.
Note: I do not own any DK products or stock, nor do I have any commercial relationship with them. My current favourite keyboard is a TKL with cherry brown switches, so a similar format to this, but mine has ridiculous RGB backlighting because I LIKE IT WHEN IT LOOKS LIKE NYAN CAT and I just turn off the backlight if I'm playing something that's meant to be scary like Stalker or Metro.
Yes but slower. Java is every 6 months. Firefox release every 4 weeks, Chrome every 6 weeks.
If you look at just the LTS releases instead, those are on a 3 year cadence. Current LTS is Java 11, next should be 17.
The LTS releases get free public updates for a while (nominally about 6 years). The every-6-months releases get *no* free public updates once the next one is out (!). There was some controversy over that because it doesn't give users of the frequent releases any overlap in the support periods to test JVM upgrades.
> I very much favor IDEs that use text files for build/project configuration
FWIW VS Code satisfies this too. All the VSCode-specific per-project settings(*) are JSON-with-comments files in a ".vscode" directory. Building from the IDE generally invokes the same CLI build tool as you'd be using if you weren't using an IDE at all & will be using the same build config files as you'd have on CI.
(* this is mostly stuff like, say, launch.json tells VSC which binary to invoke when you press F5 and whether or not to pop open the mini-terminal when you do so.)
> I HATE having to drill into a dialog box every time I want to change my build settings, include paths etc.
On that note, have you ever tried using XCode? Now there's a huge bundle of endless suffering.
> Java file? Ohh, that's big. I'll gzip it
Please tell me they didn't gzip a .jar file? Those are already zip files, compressed with deflate!
(You may get a little more compression out of them because zip compresses files one at a time, but rarely an interesting amount.)
> Log file? Ohh, that's big. I'll gzip it. Log rotation breaks.
Log rotation should already have been gzipping yesterday's rotated copy. ;)
As chroot mentions in the other comment, browser vendors eliminated the visual differences between EV and non-EV certificates a while back.
Empirical experiments were run & demonstrated pretty conclusively that nobody was checking for (or cared about) the extra UI widgets browsers used to put in the address bar for EV certs. In general, people do notice negative security indicators ("not secure", red bars, etc) but they don't notice the absence of positive security indicators (like https markers).
(When I say "nobody", I mean really, nobody. Not just lay audiences: people in IT, programming and information security too.)
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2021
