I think Win2k already had that. As far as I remember, the explorer sidebar, the white box with the colored line under the heading, already being HTML.
I loved hacking on that back then to customize my windows experience.
If you changed the colour scheme on Windows 98, none of the cloud images were transparent in Explorer (they assumed the background was white) so you'd end up with these weird clouds/sky fading into a white background and then a hard line into whatever colour you'd set your background to.
The desktop was very sluggish if you added an active desktop to it, as IE4 had to run; at least it was on my underpowered machine. Additionally it came with a screensaver that you could interact with, which was odd because normally moving the mouse dismissed the screensaver.
I've been using FairEmail[1] for some years now as a replacement and find it superior to the gmail app. Of course, depending on your needs and tastes, I could also understand calling it a bit clunky. It is FOSS, but has a one time pay premium option for some advanced features. But really, it's also just fair to support the dev by buing the app.
My only complaint would be, that there are to many updates, but of course, you can just ignore them and do them every few months instead.
And the pandora took years to arrive, got constantly more expensive while waiting, while the hardware got pretty long in the tooth. Still, it was a greadt device! But when it arrived, it was already a curiosity from another time and I feel this even more so for the Pyra.
I had a similar idea a few years ago and tried to set it up, but failed at making it easy to connect to.
I wanted the phone to prompt you like when connecting to wifi hotspots where you have to accept some T&Cs before you can connect to the internet, but to then just show you the local services instead of actually offering internet. Honestly, this can't be that difficult, but at the time, I could not get it to work reliably.
I think they just confused bavria with munich. It was the city who had their own linux distribution (LiMux) and the move of the headquarters where part of microsoft efforts to change that, because it means more tax income for the city (Munich is not part of the disctrict Landkreis München).
It's "Rattenfänger von Hameln" in german, so the literal translation would be "Rat-Catcher of Hamelin".
I do remember him wearing brightly colored patchwork clothing in the stories, but I could not say if that was an integral part of the original fable or just added in retellings to make the character stand out more as a mysterious stranger.
Not sure, the costume reminds me of a jester. If I'd take a jab at it, here is the original transcription from Brüder Grimm:
"Im Jahr 1284 ließ sich zu Hameln ein wunderlicher Mann sehen. Er hatte einen Rock von vielfarbigem, bunten Tuch an, weshalben er Bundting soll geheißen haben, und gab sich für einen Rattenfänger aus…"[0][1]
"In the year 1284, a strange man appeared in Hameln. He had a skirt, made from differently colored fabrics, which is why his name was 'bundle(?)', pretending to be a rat catcher…"
It would not surprise me. Clothing took a lot of labor to make. A large part of the labor was women's labor which history doesn't record much of. When you are doing that much effort it isn't that much more to die in bright colors, and people like colorful clothing (some like the Amish make non-color part of their identity of course, but they like colors they are just rejecting them anyway because they think that helps them get to heaven). Colors were limited to what they could make so probably not as bright as modern, but not dark in general.
> A large part of the labor was women's labor which history doesn't record much of
Women spent much of their lives making textiles. It likely wasn't recorded much because it was so ubiquitous.
For example, my family photographs when I was growing up were nearly all about documenting unusual events, like birthdays, holidays, and vacations. The humdrum ordinary things were not photographed. For example, there was only two photos with the family car incidentally in the frame. No photographs of the neighborhood. One photo of the school I attended. No pictures of my dad at work. No pictures of my mom cleaning the house. And so on.
The ones who can read and write expect to be paid, and the wealthy and powerful will commission them to write about what interests the wealthy and powerful - i.e. themselves.
This state of affairs persisted until the advent of the printing press, which made for a mass market of ordinary people.
Bright colors fade more noticeably over time, so bright clothing was a good indication of new, regularly replaced clothing. The dyes themselves could also be phenomenally expensive. The scarlet red of Catholic cardinals was historically made from Kermes, an especially lightfast dye. Kermes was in turn a cheaper alternative to the Tyrian Purple worn previously.
Daily clothing would have been more pastel than the saturated colors we associate with "colorful" today.
The question is of course always where someone draws the line, and thats part of the problem.
Too many people have the "Premature optimization is the root of all evil" quote internalized to a degree they won't even think about any criticisms or suggestions.
And while they might be right concerning small stuff, this often piles up and in the end, because you choose several times not to optimize, your technology choices and architecture decisions add up to a bloated mess anyway that can't be salvaged.
Like, when you choose a web framework for a desktop app, install size, memory footprint, slower performance etc. might not matter looked at individually, but in the end it all might easily add up and your solution might just suck without much benefit to you. Pragmatism seems to be the hardest to learn for most developers and so many solutions get blown out of proportion instantly.
> Too many people have the "Premature optimization is the root of all evil" quote internalized to a degree they won't even think about any criticisms or suggestions.
Yeah I find it frustrating how many people interpret that quote as "don't bother optimizing your software". Here's the quote in context from the paper it comes from:
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
> Yet we should not pass up our opportunities in that critical 3 %. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.
Knuth isn't saying "don't bother optimizing", he's saying "don't bother optimizing before you profile your code". These are two very different points.
I like Knuth and think he’s a great writer, but this particular paper [1] is… hard to read. Almost as if it is an unedited stream of consciousness rather than something he intended to be published.
Reading the section you are quoting from (as well as the section of the conclusion dealing with efficiency), I think it should be clear that in the context of this paper, “optimization” means performance enhancements that render the program incomprehensible and unmaintainable. This is so far removed from what anyone in the last 30+ years thinks of when they read the word “optimization” that we are probably better off pretending that this paper was never written. And smacking anyone that quotes it.
I actually think it's a lovely paper (and he obviously intended to publish it, and put a lot of effort into compiling and editing it) and illustrates the nature of his writing very well: he's managed to be encyclopedic about all the topics he chose to discuss, while still having it be very personal (the matter at stake is one of programmers' style and preferences after all). This blog post (https://blog.plover.com/prog/Hoare-logic.html) calls it “my single all-time favorite computer science paper” and here's a recent HN thread with at least two others agreeing it's a great paper: https://qht.co/item?id=44416265
My boss (and mentor) from 25 years ago told me to think of the problems I was solving with a 3-step path:
1. Get a solution working
2. Make the solution correct
3. Make the solution efficient
Most importantly, he emphasizes that the work must be done in that order. I've taken that everywhere with me.
I think one of the problems is that quite often, due to business pressure to ship, step 3 is simply skipped. Often, software is shipped half-way through step 2 -- software that is at best partially correct.
The pushes the problem down to the user, who might be building a system around the shipped code. This compounds the problem of software bloat, as all the gaps have to be bridged.
I've never interpreted "Premature optimization..." to mean don't think about performance, just that you don't have to actually implement mechanisms to increase performance until you actually have requirements to do so - you should always ask of a design "how could I make this perform better if I had to".
To me, it rather meant: "Ultrahard" optimization is perfectly fine and a good idea, but not before it has become clear that the requirements won't change anymore (because highly optimized code is very often much harder to change to include additional requirements).
Any different interpretation in my opinion leads to slow, overbloated software.
It is forever baffling to me that so many devs don’t seem to appreciate that small performance issues compound, especially when they’re in a hot path, and have dependent calls.
Databases in particular, since that’s my job. “This query runs in 2 msec, it’s fast enough.” OK, but it gets called 10x per flow because the ORM is absurdly stupid; if you cut it down by 500 microseconds, you’d save 5 msec. Or if you’d make the ORM behave, you could save 18 msec, plus the RTT for each query you neglected to account for.
I've found that mentioning bloat is the fastest way to turn a technical conversation hostile.
Do we need a dozen components of half a million lines each maintained by a separate team for the hotdesk reservation page? I'm not sure, but I'm definitely not willing to endure the conversation that would follow from asking.
What I once said to a less experienced developer in a code review is:
> Don't write stupid slow code
The context was that they wrote a double-lookup in a dictionary, and I was encouraging them to get into the habit of only doing a single lookup.
Naively, one could argue that I was proposing a premature optimization; but the point was that we should develop habits where we choose the more efficient route when it adds no cost to our workflow and keeps code just as readable.
And to add to that, because some people might not know or have forgotten, colors where easily adjustable in winforms, so dark mode, high contrast mode, green, blue, hot pink etc. were all easily adjustable for all these apps and back in th day that was pretty standard to do for visually impaired people.
No extra work from programmers was necessary, so vastly superior to today where you have to beg for good dark mode support.
"Dark mode" today is the biggest scam - selling us a neutered form of color schemes that used to be a standard feature of any UI toolkit as something new and exciting.
It's quite interesting, that while this topic comes up from time to time (it has been going on a long time after all already), people on here seem to seldom talk about the organizations that lobby for this proposal for years, with big ties to the US and intelligence agencies. So this is by no means just an European phenomenon but there seems to be a much bigger agenda behind it all.
Now, at the moment, I don't have a good english language source, but I am sure someone else could provide one?
Here is a german language one[0], from netzpolitik.org, who follow chat control for years now an have many articles going in depth about this. I am sure you could use translation software to read it until someone provides a better source. (And if you have not heard of this, you should!)
And while someone already linked to patrick breyers website[1] which has a good overview, I do so again so maybe more people will see it.
This thing is not new, but it is also not easily ignored and everyone should be informed whats going on here. They will try to pass this again and again since they have done for years now and it's mostly been close calls until now.
This is a good time to remember the short span when Firefox actually would show an RSS Symbol in the address bar after it found a feed on the page, allowing you to click on it to view it and subscribe. I thought, the future of RSS was bright back then. They removed it shortly after.
That they removed even the formatted feed view a few years back was just an insult!
But they could also never manage to cash in on microformats. So much potential there.
When I'm familiar with the source, the headlines are enough for me to know if I want to read, navigating the folders is super quick, and the feed indicator makes adding new ones very easy too.
_V1_367.jpg){kind=link}
_V1_368.jpg){kind=link}
reply