The US should really nationalize their rail infrastructure; only the rails themselves, not the railroad companies. The railroads should be treated as transportation infrastructure the same way that the highway system is.
With nationalized rails, the US could set standards for rail-sharing which could help passenger rail and invest in improved rail connections between cities which would improve both freight and passenger rail service.
Currently, each railroad company gets to maintain their own little fiefdoms in certain parts of the US
This is still possible. There's nothing stopping you from putting comments in the JSON in your file or a webpage. It's just not going to be accepted as valid by JSON parser, which for learning material should be fine.
> The 10th time, the 50th time, I still needed the GPS to guide me.
If anyone else is frustrated by this experience, I've found that changing the setting in Google Maps to have the map always point north has helped me with actually building a mental model of directions. I found instead of just following the line, it forced me to think about whether I'm going north, south, east, or west for each directions.
So much this! GPS ego perspective directions prevent developing any kind of mental model.
It's the same reason I hate that trains in Germany now only show when the next train comes. When I was a kid they would show the time and optionally the delay. I always knew when each train was coming because you learn the schedule automatically. Now it's impossible to automatically build that mental model.
Large corporations buy Windows _because_ they can have this level of control over their machines. The CTOs and auditors want to be able to say they've personally secured their systems using "top of the line" security software.
This is most likely due to those names not being allowed for files or folders in the Windows file system. MS Teams channels create a matching folder in SharePoint where file attachments are stored.
Every time, it seemed like it was going to be so easy and powerful. Each time, it turned out to be impossible to implement relatively vanilla functionality.
I worked at a bank that had a windows-based trading system and for some reason created folders to hold the details of each book. There were issues when a trader decided to call a book "LPT1".
I've spent the last 20 years of my career working for investment banks. Never seen a windows based trading system. Frankly picking windows as a target platform for trading infra is asking for trouble. Everyone seems to know that and build on top of Linux. When was that?
No, it's most often not related to any particular client. Rather the book is a list of all buy and sell orders that didn't match sitting there and waiting for someone to take the other side of the trade
\\?\GLOBALROOT\ anyone? Now you're opening devices from the NT object namespace rather than files.
Bonus: You can create the file C:\con\con using NT Native API filesystem calls. Someone even made a video of installing Windows into C:\con\con, and the kernel-side stuff works beautifully, and the explorer shell side dies horribly.
At some point, I think it would only play sound files in the program's folder. I have the vague feeling that it was later changed to an AOL-created subfolder unique to each Windows user.
> AFAIK, everything else is fair game, even emojis
FWIW, I generally expect emojis to be more compatible than other symbols, because they have no legacy meanings - ex. ™ has never been a path separator, or indeed anything else.
Main problem with "emojis" is that they live outside the basic multilingual plane, and so make bad utf-16 handling really obvious. This is a blessing in disguise, because it acts as a no-brown-m&ms thing, since it's more unarguably broken than not being able to use cuneiform, or musical symbols.
Yeah, point; I probably should have said something more like "emoji shouldn't have alternative meanings, so they should work if your unicode support is functional (which is a big caveat)." On the bright side, yeah, emoji have been great at pushing things to handle unicode nicely and act as a... I dunno, natural fuzzing case?
Oops, good point. I think I'm going to leave it as-is on account of not knowing of any actual emoji that HN allows, but yes that is technically incorrect on my part.
Speaking only for myself, the confusion comes purely from the fact that I think of all text as "ASCII" or "Unicode" (...or "something else that nobody should use in the modern era"), and I don't really distinguish within "valid unicode that isn't ascii".
And it was merely not recommended to use a fullstop at the start of a filename. Device drivers —perhaps just for storage devices — were usually named this way (and also marked invisible). There was an alleged chance the OS would try to load your non-driver file as a driver for the device it resided on. Though I was unable to make it happen.
NTFS itself has not that many forbidden characters (though ':' is one of them, it denotes alternate stream).
What people think about those CON, PRN, AUX, NUL etc are not filesystem limitation.
And while we are here - nor backslash, nor forward slash are used in NTFS. It can care less about what char do you use for a directory separator. Just be sure to update your APIs.
NTFS on non-Windows systems aside, I wonder whether there are any "pure NT" environments you can access in Windows where you can create and use these folders.
You just need to come in below whatever layer notices them. I'm sure they've been used to smuggle viruses in, so the layer that blocks them may get lower and lower.
> [...] and only disallows the ascii slash and null. All other bytes are fair game.
There's also the special treatment of "", ".", and ".." (that is, a file or directory name consisting entirely of zero, one, or two dots), and the convention that a name starting with a dot is hidden.
Yes, and it was an absolutely horrible mistake in the other direction. If I give you a path “./something/example.txt” it could be a file called example.txt in a folder called something or it could be a single file called “something/example.txt”.
> : on disk, in classic Mac OS, and at the Carbon layer in macOS; / at the Unix layer in macOS
APFS:
> In the Finder, filenames containing / can be created, but / is stored as a colon (:) in the filesystem, and is shown as such on the command line. Filenames containing : created from the command line are shown with / instead of : in the Finder, so that it is impossible to create a file that the Finder shows as having a : in its filename.
It doesn’t make sense tbh, it just causes confusion when someone is using terminal. Slashes in file names are forbidden everywhere except Mac, it needs to be changed in order to send it anywhere or use in some apps. But I think colon is used much more in names. I don’t get why did they do that.
Given the preponderance of 3 major operating systems, I'd think it's sensible for user-level applications to disallow creation of filenames that would cause problems on any of them. Except arguably that could even include using spaces or periods... obviously in an ideal world such restrictions wouldn't exist, but I'm not sure how to realistically push for such a world. E.g. my suggestion would be to reserve non-printable characters (below Ascii 32) for use as separators/delimiters in as many contexts where that's workable. Obviously some sort of convention would then need to exist as to how they were displayed and typed in, and I very much doubt I'll ever see it happen, but I'm sure it would solve a lot of mis-parsing bugs that show up with frustrating regularity.
I see your point, but forbidding slashes, the weird Windows reserved names, maintaining case insensitivity (also Windows), and forbidding colons doesn't seem like the craziest restrictions on file names. It can definitely get out of hand, though, if you start excluding too much stuff. IIRC, Azure doesn't even allow slashes in storage account names which greatly limits naming schemes and goes too far in my opinion.
Slashes are used in paths, so most programs that aren’t Mac-exclusive would use them to build a path to file. To make it work properly in cross-platform programs you’d need to write platform-specific code to handle that. It just adds complexity and possible errors. Even system terminal doesn’t display it as slash and it doesn’t work if you write slashes.
For users of other platforms (at least 90% of desktop market) it would just display as slashes. Just not implementing this workaround would make it predictable when moving and using files.
Once I planned to share files between a Mac and a Win PC through a product synching folders but gave up very soon due to the constant errors and problems with file names worked in one but not in the other, dominantly filenames that I did not choose but received (e.g. link dragged from address bar to folder, but others too) but some I choose following some preexisting logic.
And matching Active Directory groups. It's kind of cool to use them, because it's a really easy way to let the users administrate access to resources without opening a support ticket.
But it now has a feature to integrate seamlessly with OneDrive, linking or replicating a folder on the user machine. Hence, I expect it has the same limitations in terms of naming.
OneDrive for Business (not consumer!) is SharePoint. It has the same restrictions as SharePoint (nb: because they're separate Web Applications, Microsoft can enable/disable features independently between "OneDrive" and SharePoint).
Yes, OneDrive client is restricted by the Win32 API in terms of allowable file names/path length (which is now 32k but Office doesn't respect MAX_PATH and implements its own ~250 path length limitation).
With nationalized rails, the US could set standards for rail-sharing which could help passenger rail and invest in improved rail connections between cities which would improve both freight and passenger rail service.
Currently, each railroad company gets to maintain their own little fiefdoms in certain parts of the US
https://public.railinc.com/about-railinc/blog/who-owns-railr...
reply