Recently posted comments

Additionally, did someone ask the Turkish people? (PHP fucked them up, because the word “function” contains a dotted i, and PHP insists on being case-insensitive…)

There, I ≠ i because they have I ↔ ı and i ↔ İ so you need locales.

This is the ultimate proof that case-insensitivity cannot (and therefore MUST NOT) be done on the filesystem level.

Given the diverse range of opinions often exhibited on other subjects by Debian Developers, I feel quite confident that were there to be any significant number of Debian Developers who felt that your interpretation was the most appropriate, a draft General Resolution to that effect would have been proposed, and most likely sponsored, by now.

I see no evidence that any Debian Developer has proposed, let alone sponsored, a draft General Resolution suggesting that your interpretation of the Debian Constitution regarding who is eligible to make nominations for DPL and who they are allowed to nominate should be preferred.

On this basis, it seems to me that your position on this subject may safely be dismissed by third parties as invalid.

In both L4S and SCE, routers only operate on the IP header. They do not inspect or alter the IP payload, including TCP headers. The "higher layers" only run on the endpoints. L4S does not violate the normal layering rules in that sense.

For example the DDs could if they chose elect a DPL who was not a Debian Developer but had the management skills they wanted.

Or a DPL who espoused policies that the cabal opposes.

Well, that assumes that there is a valid candidate. AFAICT, he isn't a valid candidate because he doesn't meet the prerequisites (being a Debian Developer). No different than not allowing a 20-something on the US Presidential ballot (one needs to be 35 to be eligible). The Debian constitution would need amending to allow non-DD candidates first.

L4S now proposed to use the same codepoint to let flows promise the AQM that they will respond differently to CE marks than TCP-friendly flows. Specifically these flows promise not to interpret a CE mark as a strong signal to scale back their sending rate, but will look at the ratio of unmarked an CE-marked packets to get a pulsemodulated signal of the AQMs load/congestion state.
The challenge is that an AQM needs to know how flows are going to react to CE-marks to send the appropriate signal to each flow, otherwise the flows responding milder to CEs will suppress the ones with a strong response.

So in both cases the idea is to send a graded congestion signal so the endpoints can try to respond with more finesse than current TCPs with the binary congestion signal can. The main difference is how backward compatibility is handled. IMHO the SCE approach seems cleaner an more evolutionary than trying to press the ECT(1) codepoint into service as an identifier, as in the L4S approach endpoints never know whether a CE mark comes from an L4S AQM or from a traditional one due to the fact that ECT(1) will only identify packets that have not yet encountered congestion unambiguously...

But the long-suffering DDs might have chosen a leader who was not a member of the current cabal.

It's really easy to misunderstand that part at first ;-)

I will say, a platform for a leadership position should not be based on past grievances and disagreements, especially if the nature of those issues is not precisely spelled out. The linked message does not, for the most part, describe those issues in any detail. In a way, this is good, since many of them sound, based on the vague descriptions, like personal issues. But again, personal issues and bad blood do not a platform make.

That, and his subsequent cries of censorship, incline me to believe the Debian community is acting correctly by not considering him a serious candidate.

Different incentives? Like O.J. Simpson proving that the gloves don't fit?

I loved the sentence
"Thinking in terms of this quarter's numbers and how to accelerate growth are, arguably, not even sensible for for-profit companies, but they are likely not at all right for most FOSS projects."

So true !

What it does mean is that your case insensitive lookups for the file system are actually case sensitive with insensitive elements. How sensitive it ends up being depends on what language a user uses.

Unless, of course, the kernel is aware of the user's locale and changes the responses accordingly.

Also, I don't think you can blame Unicode for the fact that Turkish and English has different alphabets.

That's the part people object to, because they are used to the simplicity of pushing encoding problems somewhere else, with "filenames are streams of bytes". Which was not true even for original UNIX. Actual original Unix filename bytes were 7bit ASCII bytes and nothing else.

But 7bit ASCII is useless in a modern i18n world. So you need to record other pivot encoding(s) in filesystems¹.

¹ Record, not reproduce the mistake of original UNIX, that assumed there was a single encoding that would never evolve so there was no need to make it explicit; easy mistake to made in the simpler computer age they lived in; inexcusable mistake to make today.

There's another problem here. Correct case folding is locale dependent. One example: Turkish has an i and an ı (i without the dot). Unicode helpfully has an İ (capital I with a dot) right next to it. Guess what happens when you case-fold these in Turkey vs. everywhere else.

As someone who is a native English speaker: I'm not sure.

I would normally expect the word "bastardization" to be used about inanimate objects or abstract concepts, not about people, meaning replacing them with a crude or low quality form of the same thing. For instance (to stay somewhat on-topic) if a software vendor uses dpkg-deb to put their binaries in a .deb file without going via a source package or filling in the metadata correctly, we might call that a bastardized form of Debian packaging.

He might have meant something like denigration, disparagement or vilification?

"The UTF-8 patches incorporate these rules by processing the provided files into a data structure in a C header file. A fair amount of space is then regained by removing the information for decomposing Hangul (Korean) code points into their base components, since this is a task that can be done algorithmically as well."

Exporting these non-standard tables to userspace would lock in this custom format implementation detail forever.

You can try a happy case and just attempt an open() with the provided name. If it fails, you need to scan the directory to find a matching file with a different case.

And you can't really cache the negative result, patterns like "if !exists(fname) {creat(fname);}" are exceedingly common.

How is a call to open() getting the filename to open? Either it's going to from an existing directory scan, in which case the capitalisation/normal form should already be correct, or it's going to be because a user has selected a file - in which case the shell/picker/whatever should be able to do that work already?

Where would calls to open() be getting these correctly named but incorrectly capitalised/normalised filenames from?

P.S. I wonder if these tables (without code) could be exposed to userspace. Userspace guys ALSO often need to deal with Unicode and if kernel already has all these tables... why not use them?

fanotify is better, but it also can drop events from time to time under high load.

Always assume someone stole your filename. It isn't your until you hold a handle to it.

So how is this case normalization system helping anyone?

https://www.stadia.dev/about/#software-stack__details

• SCE adds information in the IP header that higher layers in the network stack may use to back off from congestion (like BBR/FQ?)
• In L4S the higher layers already have the congestion information through some means, those set the bit in the IP layer as an extension signal, and it's up to receivers to understand that bit and introspect the rest of the packet to enqueue it properly?

This is nature's arms race.

How does a peahen tell that her intended mate is a fit father for her chicks? A big tail is an expensive hindrance, and if he can carry that off well, then he must be fit. A female looks for *mal*adaptions in her intended mate.

Whereas males look for ways to fake that - to fool the female into thinking that he's fitter than he is. If he can make his tail-feathers thinner and lighter than other males, while still looking as good, he's using less energy looking after them, and he can make a quicker get-away when he's threatened. All the while looking good to the females ...

Cheers,
Wol

Is case-insensitive file name support the only user of this code? Then being able to handle Unicode is hardly the requirement of the world we live in - we can already have emojis in file names, after all, and I doubt those are case sensitive.

His claim that he wasn't considered a "serious candidate" is also interesting because, as mgedmin mentioned, he's not DD and not eligible for DPL. Additionally, he's making an assumption that Lamby's statement was directed toward him—a statement that I believe was clearly directed toward DDs.

A majority of his recent posts center around berating the entire Debian community, using lies and partial facts in order to reinforce his rants. This all carried over rather cleanly to his proposed platform, which just sounds like another long-winded rant. The only points of his with any value are issues that are already being discussed (DPL Team, DAM Review/Oversight, etc.).

One of his rant-points [1] is particularly interesting because his proposed platform and recent blog posts are exactly the sort of "condescending, degrading and generally abusive communications" that he's referring to.

The rest of the candidates that popped up all seem like quality people that would work in the spirit of Debian to keep pushing the project forward. I'm excited to see the election results.

[1] "No more bastardization of volunteers with demotions and other condescending, degrading and generally abusive communications"

I think by System 7.5 (or 7.1 Pro) you did, because if I recall correctly that's how File Exchange/PC Exchange did its work.

Remember, in classic Mac OS the colon ':' was the directory separator in paths, and you could use '/'s to your heart's content. Actually, you could use pretty much anything to your heart's content, including spaces, punctuation (since no one in the Mac side cared about extensions) and even weird graphs like the f-hook or florin https://en.wikipedia.org/wiki/%C6%91#Appearance_in_comput... , which I still find myself occasionally doing on OS X 20 years later.

Anyway, with /. \. and : being used in different locations, there was definitely path-mangling going on below the interface. But general users didn't have to care, and most Mac programs didn't deal with constructed path names, and *never* had to worry about shell-quoting for spaces and whatnot.

Between this freeform text attitude, the resource and data fork dichotomy, and the use of Type and Creator codes, I definitely feel like we've lost some good capabilities on the Mac side in the quest for broader interoperability.

However, I'm not sure that allowing people to create both Foo and foo and then having applications use an interface that "asks for foo" in an insensitive fashion is going to produce a lot of happiness.

I think that was the approach taken by other people too, probably one of Apple Single or Apple Double representations which probably had some solution for NFS which was still in vogue in the 90s.

It wasn't that nice an experience for the Mac users or the non-mac users. I never programmed against it to experience the extra sharp edges, though.

Would you have expected the shown Makefile snippet to work on Classic Mac OS or would an error that "no rule to make FOO" be acceptable?

[1]Making a path appear in Explorer via a network share with the name "CON1" renders as some mangled name. Creating a file with that mangled name then shows two files with the same name appear. Deleting either one via the UI deletes the one with the real mangled name first (I assume given a HANDLE, they can be differentiated).

Classic Mac OS was designed with case-insensitivity in mind, had no manual tools that needed to be imported with minimal effort rather than a complete rewrite, and had no shell mechanics to emulate.

Case Insensitivity #JustWorks when people expect it and are going through translation layers (and aren't in the business of writing drivers), and doesn't when people assume low level access.

Er, yes. I've been using Debian as my only desktop operating system for... uh, several years now, and I certainly play games (both Free and proprietary) on it.

(You get the occasional bolshy developer who ignores your bug reports if you aren't running the blessed version of Ubuntu, of course.)

It's probably safest to see FLOSS projects as marketing. I also disagree with Cheng on Trademarks -- and maybe there's good reason for large companies to be worried about FLOSS project maintainers starting to use those. Trademarks are a perfectly legitimate way to make money from FLOSS. That's how Android works. The entire ecosystem is controlled primarily via a trademark. So, if your FLOSS project is your primary marketing vehicle, that's fine; that's how most companies make their money anyway: branding. Just make sure whenever the associated trademark is used that you derive something from that. Here's Lady Ada's answer to "I would like to sell my project as a product and I'm scared of someone becoming a competitor! ": "You can use trademarks to create a brand. Trademarks are not covered by Open Source licenses so they remain your property. Trademarks are super-cheap compared to patents, and you can file for them yourself for about $275."

The crowd of older folks using older hardware's being pushed away with the dropping of 32bit support, SSE2 in glibc forcing distros hands to some degree, and generally making maintenance difficult.

Tried debian buster on a whim with the alpha 5 media a few weeks ago. I can definitely see the need for that 100 papercuts approach -- it worked in ubuntu a decade ago; but I haven't seen it referenced in maybe six years now.

There's other downstream distros that rely directly on debian too, like armbian and raspbian.

Plus, with salsa coming into the mix, my major complaint about debian (lack of PPAs / visible public build infrastructure with signing / forcing everything through the repo signature path) has mostly evaporated.

Many of the biggest annoyances stopping many people from 'coming home' to debian look to be evaporating in the face of the Buster release.

Maybe wayland/weston/libinput will even be stabilized...?

Perhaps I might even... be able to play... games...??!

And with google's Stadia announcement at GDC; along with Valve's wine/dxvk push, have resulted in Unity3D having this to say:
"Stadia will use Vulkan, so for developers that have written (or will write) custom rendering plugins and shaders that target Vulkan, please keep this in mind.

Stadia will also use a Linux-based operating system, meaning any native plugins must be compatible with Stadia’s OS. For Unity development, you’ll be able to use the editor on the Windows PC you’re using today – simply target Stadia as the platform to build.

Finally, Stadia will be an IL2CPP platform, so runtime game code must be compatible with IL2CPP in order to work on Stadia."

I think maybe it's time to head back to debian, wrench in hand. The future looks bright with LLVM8/9 and clangbuiltlinux. SIPR-V, ROCm, P2PDMA, AMDKFD, and other useful concoctions seem to be getting traction too, which will drive Vulkan ever further.

Do Android/fastboot/etc. support compiling mailine drivers as modules or not really?

It's a shame I have to destroy all these Cavium Nitrox III cards.
They're worth more as scrap since there's no software support for these CN35XX cards, only the Nitrox V CN55XX following them landing in linux5.
Ironic that it's acidic Gold recovery for the Nitrox, and the PLX switch chips get safely reballed and resold off in china...

*sigh*

Not much less. Casing rules depend not just on encoding but also locale, and while it may be practical to enforce a single universal encoding and normalization scheme you're definitely not going to get away with enforcing a single universal locale.

The logical way to handle normalization is to simply disallow non-normalized filenames. The kernel doesn't change the encoding or compare different normal forms, it just verifies that the names of new files are in a particular normal form and returns an error if they aren't. Since all names are already in the same normal form comparisons reduce to exact binary matches. The equivalent for case would be to disallow either lowercase or uppercase characters in filenames (assuming you could even clearly define what is "uppercase" or "lowercase"—it depends on the locale). People put up with that in the DOS era but I don't think it would be considered acceptable today.

The odds that encoding or normalization would be permitted to vary per-filesystem or per-subtree are negligible. Applications aren't prepared to deal with that, nor should they be expected to do so. Any conversions needed for shared filesystems should be handled at the lowest layers of the filesystem, between the storage or network and the kernel.

My initial comment was a bit rude, sorry about that.

(Also, what definition of "censorship" applies to a mailing list post that is publicly available on the web? On second thought don't answer that, I don't want to know.)

[0] https://lists.debian.org/debian-vote/2019/03/msg00001.html
[1] https://danielpocock.com/what-does-democracy-mean-in-free...
[2] https://danielpocock.com/dont-trust-me-trust-the-voters

At a trade show one of our customers said that they received a rack that was too tall for the door. It's not that hard to remove all the computers and then lean it over and carry it through. But instead of that they decided that they weren't ever going to need the top shelves of the rack so they took a chainsaw and chopped it to the right height.

This a customer so of course you congratulate them on their resourcefulness but inside you're weeping.

Having said that, having file systems encode file names as byte strings and having mechanisms to query those uninterpreted or case-insensitive (or whatever) as processes require seems to me a reasonable square of the circle.

I agree that the Gtk file chooser having case-sensitive autocomplete is daft, but... I don't actually care, because I hate the Gtk file chooser anyway for other, more fundamental design decisions.

Just because you grew up with an alphabet that has 26 letters doesn't mean that it's the only alphabet in use.

Regarding being open to newcomers, it should be obvious that nothing is more attractive than the perspective of doing something fun, challeging and that makes a difference. Debian can be (needs to be) all these things.

People are just used to broken systems (broken keyboards on typewriters and computers, broken apps, in legacy typesetting "someone broke the small bit of lead corresponding to the diacritic on the capitalized letter"). Humans habits are a huge source of inertia. When Microsoft finally got around to fix Office for French some Microsoft clients actually complained it was now correcting words to the correct spelling.

Proper typesetting shops take care to type correct french (typesetting apps correct the windows user breakage), and Linux diverged long ago from the "official" AZERTY layout to make uppercase with diacritics easy to type (French Canadians were smarter: they fixed their official layout to put caps with diacritics proeminently on them. Pity you can't buy Canadian French keyboards easily in France).

So any shared filesystem will need to export to userspace the encoding used for each part of its tree (either a single encoding for everything, or separate encodings per subtree).

Casing is something else but once you get past the encoding point casing becomes a less harder to tackle.

No, everyone involved is just doing this for absolutely no reason at all. Weird.

But this will break a ton of other software that wants to directly modify the disk files. It will also mean that Linux's VFS is inadequate for a fairly common use-case.

Déjà vu: what about kernel *modules*? Typical deployment problem on any Linux-based OS. For Android how does fastboot deploy kernel modules and where to ? I mean the mainline & GPL drivers, not vendor modules.

This page seems to refer to vendor modules only: https://source.android.com/devices/architecture/kernel/mo...

Wow, speaking of grey hair *you* must have a lot of it; you're clearly from some pre- social media era :-)

There is actually something stopping yourself from entirely disabling any form of congestion control: you'll be hurting not just the others but your own connections/sockets too.

As often one key thing missing in this discussion is the definition and boundary between "my" (headers/connections/sockets/...) versus others'; wherever is that boundary I doubt "my" describes just one socket.

https://source.android.com/devices/architecture/dto/parti...

Unless they made a new partition with a filesystem mounted in userspace that's shipped with the boot image, there's not really great a place to put the kernel headers other than the kernel. I think that may be a better solution, although it'd be Android specific and not portable.

They could come up with a scheme where they stick the headers elsewhere in the boot image, and have something like init expose access to it. The main advantage I can see with the kernel approach is that it wouldn't be only available for Android and is probably the simplest approach.

https://source.android.com/devices/bootloader/boot-image-...

foo:
touch foo
bar: Foo
cp Foo bar

Because if so, this means that tools now need to make a syscall just to do path manipulation to be accurate (something like canonpath() that would give a path which is the same for all equivalent input paths maybe by doing tolower() and normalization). And it has to work for paths that don't exist yet. And I don't think that can even be correct because that path might end up having a bind mount in there at some point which changes behavior (yeah, low chance, but kernels don't always have that luxury).

Yeah, case insensitivity might be useful at the UI level, but even there you still have to deal with paths using binary data or invalid utf8 because a file that the GUI can't delete is a wonderful thing to diagnose and resolve. Personally, I don't find it that useful (but I encourage you to file an issue against GTK for the completion thing).

I don't know if that makes sense from the perspective of the chip real estate budget, would that area be better used for cache or something more mundane, would FPGA change the manufacturing cost? It's an interesting idea anyway

I was disgusted just last night to discover a Gtk chooser dialog's autocomplete was case sensitive. In a GUI. In 2019. Total disconnect between Linux and what the real world has been doing successfully for decades, and what actual users expect. No doubt someone will pop up to say 'but I prefer it that way', well, you're free patch whatever brainwrong you like into your desktop, but most people cannot and do not want that -- it's why contemporary developers are walking around with MacBooks rather than Linux boxes

Was disgusted just last night to discover a Gtk chooser dialog's autocomplete was case sensitive. In a GUI. Total disconnect between Linux and what the real world has been doing successfully for decades now..