It's pretty obvious that instead https://darkkhaki.bikeshed.com/ is the correct URL. Everyone knows.
SCNR
968 karma · joined December 4, 2018
Socials:
- github.com/warpspin
---
SCNR
Not sure he ever tried supporting that. We once did and it was a nightmare. People couldn't handle it at all even with screenshotted manuals.
My personal experience says that even the dumbest user is able to use FileZilla successfully, and therefore SFTP, while people just don't get the built-in WebDAV support of the OSes.
I also vaguely recall that WebDAV in Windows had quite a bit of randomly appearing problems and performance issues. But this was all a while ago, might have improved since then.
This is why you should always be wary about re-implementing OS behaviour yourself in your widgets, you will always miss at least one detail, but more probably dozens of them.
Can somebody who runs this on one of the recommended Dreame mopping robots say from experience whether you actually lose some kind of essential features the built-in firmwares have? The "why not" page says feature parity is a non-goal but only specifically mentions multifloor where I can understand the reasoning.
Especially since the release of Turbo Assembler in 1985, serious development on the C64 was quite comfortable.
Years later in the 90ies, Fairlight enhanced Turbo Assembler with REU support, which made development on the machine itself ridiculously comfortable. Basically the only thing missing I can recall was there was no concept of version management back then.
Of course, this came too late for professional development but it's basically what the demo scene ran on till cross assembling from PCs came in vogue.
Reality is, as you already implied: in practice you cannot "be careful" except avoiding obvious malware.
At SOME point you have to trust SOMEONE, unless you use TempleOS in which case you can trust whatever god you have.
Not trying to downplay ESCOS - it was an important effect and release, foundational even. Just has nothing to do at all with FLI, NUFLI or now this NUFLIX variant, except that it was another nice and important timing-based VIC chip hack.
Well... They'd need to bring back 32-bit support also then. This is what killed most of my Mac-compatible Steam library....
And I do not see that happening.
That day will either happen or not in my lifetime. If it happens, no amount of interacting with shitty 2025 tools will prepare me for that because as soon as any such tool would actually understand what it's doing, no amount of weird coping strategies people develop for the current generation of tools will be necessary or work anymore.
So I can just sit back, program as I always did and just wait for the day till this stuff is actually more efficient than me in coding. Then I switch to that tool and no amount of prompt massaging knowledge from yesteryears will help me with that.
And then I need to wait for the tool solving what's usually really holding me up in my work, namely guessing the best future design based on incomplete current information from the present.
When that day comes, I will start to worry about my job. Not earlier.
You're conflating tax with tariffs here. EU does not have a de minimis rule for tax - you always pay tax on import - but it does have a 150 Euro de minimis rule for tariffs.
SCNR
Unfortunately (though I think this is a regional thing also - Luhmann's still pretty strong in Europe, especially in Germany where "systems theory" has become synonymous with Luhmann's systems theory, but not so much in the USA, I think).
One of the problems with Luhmann stems directly from his Zettelkasten: His tendency to tear citations out of their original contexts and name drop witnesses for his own point of views where the original text did not support his view at all.
You can see the system at work actually: He truly made a lot of stuff his own in ways never intended by the original authors - boon and bane at same time.
The discussion here where people explain in which ways it is misleading and thereby saving me lots of time reading this myself has a worth of itself IMHO.
Guess others might feel the same.
Might be true. Not familiar with Amiga scene but the following actions were always mostly ok in the European C64 scene, provided credit was given to original author:
* Re-using music in whole
* Re-using fonts
* SOMETIMES re-using small parts of graphics
It always was not ok and considered "stealing" to re-use complete demo routines though for example.
People did get away (reputation wise) with re-using code routines for tools, though, provided credits where given and the re-released tool somehow improved on the original.
Another thing which many people disliked for example was re-using "instruments" from music, even when melodies changed. While the players were mostly open tooling, specific instruments/sounds for those players still had to be crafted first and I witnessed a couple of conflicts when people reused the instruments.
Nothing was written in stone, though. A concept such like licenses did not exist.
I fear you're mixing it all up :-)
Most stuff in supermarkets is labelled only with a EAN or UPC code. While EAN codes carry a country code, it's only the country code of the GS1 country branch which dished out the code range to that company, which does not necessarily mean the product is from there, while UPC codes say even nothing at all about countries.
The document you linked to instead is for the full GS1 standard, like it's e.g. often used to track pallets, shipments etc. A GS1 Code 128 code for example can carry all kinds of information, dependent on the Application Identifiers there are in the code - which are explained in the document you linked to. But you will absolutely seldomly see a product tagged with a (long) code like this in a shop. These kind of barcodes get huge soon and are mostly used in shipping or storage.
Basically, to REALLY know where a product is from, you'd need a full UPC/EAN database plus do some tracking what kind of company is behind a certain number range. No such official database exists, there are a few inoffical ones though.
Looks pretty feature complete. Had just a small problem where there was a small icon with three dots to right, probably supposed to show more icons, but then doing nothing.
Also, the icon list would profit from grouping, meaning some distance between groups of different icons. Especially, put the icon to switch to "turn off" the extension far away from the others.
Oh, and please add an option to increase the toolbar buttons to at least 4x their current size. Some of us are ... getting old.
Give me a Mozilla focused on Firefox with people providing funds regularly having a certain amount of votes that will actually be respected on bug reports/broader feature requests, and I'm in.
We still use it for all kinds of web services development work, mainly because there's years of in-house modules for everything and the malleability Perl has.
Cannot support it has horrible performance. Civ 5 and 6 were notorious for having minutes-long turn change times in later eras. Civ 7 seems to finally have fixed that problem for me.
There's some annoying things in it (and also the way they basically copied Humankind leaves a sour taste) but performance it's not, for me at least. It's finally a Civ again with acceptable performance and I hope it stays that way.
Only you can decide whether it's worth it for you - this depends on how many of its features you can actively use.
I also do not find it crappy, as otherwise written here. API is pretty solid and mighty (still, only ever used it with vanilla JS, not with frameworks - things might feel different with frameworks) and documentation is good enough. Occasionally have to look up stuff in its sourcecode though.
Otherwise: There's an open source version. Unless you need the features marked as "enterprise" features, you can at least try out the integration already. There are some pretty elementary features like row grouping part of the enterprise version, though, so do not assume you'll be able to actually stay on the community edition.
I'll say this as someone who still does more than 80% of his backend work in Perl: This is not true. I wish it was.
CPAN was awesome once. Now it's mainly old. Yes, you will find obscure things which you won't find for Python. At same time, anything interfacing with modern stuff is often only 40% done in CPAN or not at all compared to the Python, PHP or JavaScript eco system. Not talking about data science stuff here, where Python gained a huge lead - simply have a look at how much support you get nowadays in CPAN for interfacing with, for example, current web api versions or interfacing with third party files like docx, pdf, excel, odt. If there's support for things at all, it is so far far far behind to what libs in other ecosystems have to offer, most of the time.
It simply shows that the crowd implementing business applications went elsewhere, so anything in that area seems stuck in the 2000 to 2010s in CPAN.
What does it support? Plain JSON Arrays? ND-JSON?