I've a smallish lawn so I've just been using wired yard tools my whole life. Have to be careful to mind the extension cord but it's dead simple and zero-maintenance. My lawnmower is just about old enough to run for President. Just make sure you get the right cable gauge for your mower, since you're dealing with long-enough runs that resistance loss in the cable is substantial and Home Depot just wants to sell you 100 foot 16 gauge thing that probably shouldn't be anywhere near a proper lawnmower.
In 1-on-1 it would be awkward to call it out but in a group meeting where I wouldn't be singling a person out it'd be pretty easy to just ask "could whoever's in the bathroom please mute?" without any kind of confrontation.
Imho the real strength of markdown is it forces people to stick to classes instead of styling. "I want to write in red comic Sans" " I don't care, you can't".
And markdown tables are harder to write than HTML tables. However, they are generally easier to read. Unless multi line cell.
I was going to respond that HTML was the original syntax and XML the usurper, but a comment in another thread casts some doubt on that version of events: https://news.ycombinator.com/item?id=46576844
As somebody who's doing the same thing for the first time in almost 2 decades: kubuntu wins for me.
Mint was too buggy. It just felt so single-threaded. It had upsides - easiest Nvidia support for example. Cinnamon is nicely customizable and has some great ideas but it's just too rough around the edges.
Raw Debian was just too hard to get Nvidia drivers playing nice.
But for "I'm comfy editing config files but I need some hand-holding for this" KDE with Ubuntu is the best balance of performance and clean design and support.
My biggest disappointment is how little batteries-included gui I'm seeing for core Linux functionality. Where is the systemd service manager? Why are all the file managers so bad at editing permissions?
Government banning insecure open standards and then not providing a secure open standard is atrocious. If I must have an official authorizing thing to prove I'm who I say I am, make it as small as possible.
If you mandated that they have to support Yubikey or whatever on open platforms I'd take that as a decent alternative. But just "no you must use a device controlled by somebody else" is not acceptable.
YAS!! The option is to provision an key from a server tied to a national id and downloadable only to specific device. BUT NO!!! Just ban things instead of doing the right thing!
Hilariously the only impressive thing I've ever heard of made in AI was Yegge's "GasTown" which is a Kubernetes like orchestrator... for AI agents. And half of it seemed to be a workaround for "the agents keep stopping so I need another agent to monitor another agent to monitor another agent to keep them on-task".
Well, that's a question for OS level. If the OS doesn't require the user to download the language and so language-switching to a new language is doable as an offline operation, I could see it being frustrating that switching to a new language must be done online.
So compression/deduplication is probably the better option. Rather than storing as 1 zip per language, though, you'd probably want a compression format that also eliminates duplication that may occur between languages if you're storing all languages compressed on the system. That means you'd need compression to handle the entire language complex being in one massive compressed blob and you'd just extract out the languages you needed. I assume there are some forms of zipping that do this better than others.
Imho there are 3 separate classes of notifications
1) Ads - these should not exist, really, or at worst should be flagged in the app store as an anti-feature isolateable from other notifications.
2) "Recommendations" - that is, stuff you didn't subscribe to but are things the app offers that they "think you would like". These are defensible but should never ever be mixed with...
3) Stuff I actually explicitly subscribed to.
Breaking these rules should be rejection from the app store. Especially now that Google is legally required to allow 3rd-party app stores, they have much greater grounds to properly curate the Play Store. Let the filth live on 3rd-party stores.
1) Why is it using an NIH format instead of using XML or INI or something?
2) Why does it use symbols instead of words for selectors? HTML calls them "id" and "class", why does CSS call them "#" and "."? Yes you learn that quickly, but terseness isn't really defensible when the verbosity already exists in the other file that you download and edit more frequently.
3) It's too global. This is good for consistent styling but bad for modularity.
4) It's too much of a moving target. Best practice for html+css+js changes constantly.
5) The long history of stuff like "centre a div vertically" shows how it fails the "easy things easy and hard things possible" test.
6) Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
I mean there are good reasons for it to suck. Anything that has grown organically since 1996 with no coherent versioning or deprecation strategy is going to be a hot mess. But it is what it is.
1) doesn't seem to be a very big issue, the syntax is quite simple and readable. Arguably, INI or XML would have been worse. INI especially would have been a shame, now that we can nest blocks. XPATH selectors would have been nice, they are more powerful and barely less readable.
2) doesn't seem to be a very big issue, this kind of stuff is very common in many programming languages as well. I don't remember struggling with this even as a beginner, and it's the first time I encounter a complaint about this as well.
3) Fair point, and the inheritance and specificity rules are very complex as well
4) On the other hand, backward compatibility is stellar (and I guess that it's your point in your last paragraph). Your 20 years old CSS file still works today and doesn't even feel really out of place. We could wish the web platform didn't evolve so rapidly, it makes it very difficult to implement.
5) It's very easy to center a div vertically now. Therefore, it can only be a critic of old versions of CSS, not the current one. Do you have another example of basic things that ought to be easy but aren't, or aren't possible?
5) Doesn't seem to be a very big issue. I wish the double colon syntax didn't exist and we'd just use single colons, but as you say, it is what it is
> I wish the double colon syntax didn't exist and we'd just use single colons, but as you say, it is what it is
Single-colon is a pseudo-class, for targeting elements based on some external state. I learned these as "pseudo-selectors" but it seems that's not the right name.
Double-colon is a pseudo-element, for targeting inner parts of an element that themselves aren't actually an element in the document.
Right! Thanks for this. I've never really looked into this and have been writing whatever worked, with a preference for the single colon.
CSS 1 & 2 apparently conflated the two, and CSS 3 allows one column for CSS 1 & 2 pseudo elements. I never noticed it wasn't all of them. Since I learned CSS right before CSS3, my situation kinda makes sense I guess.
Single colons everywhere have felt easier and more regular to me, so I've written basically everything with single colons except maybe the odd CSS 3 pseudo element here and there. But it seems the two colons will be mandated going forward.
I guess I'll have some edits to do, though I do hope and kinda expect they won't break backward compatibility.
> Why is it using an NIH format instead of using XML or INI or something?
The original suggestion was LISP-like or X.11 configuration file syntax (https://www.w3.org/Style/CSS20/history.html) - XML was still too new (but look at https://www.w3.org/wiki/Xsl-fo if you want to see what the W3C came up with for "styling, but in XML format for XML documents"). My guess is that the declarative shape imitates SGML with a C syntax to make it easier to understand.
> It's too global. This is good for consistent styling but bad for modularity.
Yeah, that was an explicit design choice - one that we're now asking for (and getting) more control over as the web continues to expand, but it's not like it wasn't considered, it was considered and rejected for MVP as it were.
> Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
Ah, cool. I wasn't sure what "here" could possibly mean when we're talking about a language that was part of the web standard.
AFAIK, CSS syntax is inspired by the syntax of STTS, and STTS intentionally didn't use XML because it's a pain in the ass to hand-write and hand-read. I cannot argue with that assessment.
So CSS's syntax was based on an existing syntax, but it happened to be a syntax that didn't catch fire (which is so often the history of such things): it made plenty of sense at the time when the devs were looking at the options and maybe went "Well, we know XSLT and... It sucks and is hard to use, so what alternatives are there?" And STTS was apparently billed as an XSLT that human beings could write and read.
reply