Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Collapse of the Unix Philosophy

kukuruku.co

Post reply on HN
Print view View original

591–600 of 616 posts

Re: The Collapse of the Unix Philosophy

#591

Post by webmaven »

int_19h wrote: post #314
eriknstr wrote: post #289

Earlier quoted context omitted.

Ruling out "bad" characters is bound to affect internationalization negatively. IMO the best approach would be to separate between file name and the file object. When I edit a file with vim, should vim really need to know the name of the file? No. Likewise for a lot of other utilities as well. If instead of being so focused on file names and paths everywhere and we operated instead mainly on inodes then I think much…

"Bad" characters in this context is control characters. So no, it would not affect internationalization at all.

> "Bad" characters in this context is control characters.

For sufficiently narrow definitions of "bad", sure.

It is probably a bad idea to allow mixed character-set filenames, as that allows homograph attacks[0], and there are other non-control characters like the zero-width space and it's brethren that should be disallowed across the board.

In English you probably also want to disallow ligature characters like fi, ffl.[1]

There are other "good idea" limitations that may affect internationalization of various languages (not in terms of making it difficult, just constraining it, as in the above English ligature example).

For example, it is probably a good idea to disallow Hebrew diacritic symbols[2] like niqqud in filenames.

[0] https://en.wikipedia.org/wiki/IDN_homograph_attack

[1] https://en.wikipedia.org/wiki/Typographic_ligature#Ligatures...

[2] https://en.wikipedia.org/wiki/Hebrew_diacritics

Re: The Collapse of the Unix Philosophy

#592

Post by int_19h »

webmaven wrote: post #591
int_19h wrote: post #314

Earlier quoted context omitted.

"Bad" characters in this context is control characters. So no, it would not affect internationalization at all.

> "Bad" characters in this context is control characters. For sufficiently narrow definitions of "bad", sure. It is probably a bad idea to allow mixed character-set filenames, as that allows homograph attacks[0], and there are other non-control characters like the zero-width space and it's brethren that should be disallowed across the board. In English you probably also want to disallow ligature characters like fi, ffl.…

> It is probably a bad idea to allow mixed character-set filenames

As someone who would be affected by this directly, I can tell you right away this rule would be a no-go. I plainly need the ability to mix Latin and Cyrillic characters in my filenames. A filesystem or OS that wouldn't let me do so wouldn't even be considered.

A very simple rule of thumb is, if it is a title of a book (or a song, or a film etc), it should also be a valid filename.

Re: The Collapse of the Unix Philosophy

#593

Post by webmaven »

int_19h wrote: post #592
webmaven wrote: post #591

Earlier quoted context omitted.

> "Bad" characters in this context is control characters. For sufficiently narrow definitions of "bad", sure. It is probably a bad idea to allow mixed character-set filenames, as that allows homograph attacks[0], and there are other non-control characters like the zero-width space and it's brethren that should be disallowed across the board. In English you probably also want to disallow ligature characters like fi, ffl.…

> It is probably a bad idea to allow mixed character-set filenames As someone who would be affected by this directly, I can tell you right away this rule would be a no-go. I plainly need the ability to mix Latin and Cyrillic characters in my filenames. A filesystem or OS that wouldn't let me do so wouldn't even be considered. A very simple rule of thumb is, if it is a title of a book (or a song, or a film etc), it sh…

Interesting. Are those filenames used in contexts where homographs could be more than a minor annoyance?

Re: The Collapse of the Unix Philosophy

#594

Post by dllthomas »

vacri wrote: post #181
dllthomas wrote: post #95

Earlier quoted context omitted.

I spent a year working on ~80k lines of bash. It was an interesting experience.

Was the primary product in bash? Or were you working on glue? You must have mastered the bizarreness of bash arrays by the end of that :)

The actual product was hosting, more or less, although with some additional constraints that meant more moving parts. The bash grew out of manual scripts to provide automation and a UI for support.

> You must have mastered the bizarreness of bash arrays by the end of that :)

I mastered a lot of the weird corners, though we mostly kept them out of the code. I've forgotten much since.

Re: The Collapse of the Unix Philosophy

#595

Post by etiene »

krapp wrote: post #450
onion2k wrote: post #386

Earlier quoted context omitted.

JSON doesn't have comments so it's a bad choice for human-editable config. YAML doesn't have an end marker so you can never be sure if you've got the entire file. XML is a huge pain to edit by hand if the schema is complicated, and overly verbose if it isn't. None of them are even close to being safe (for example https://arp242.net/weblog/yaml_probably_not_so_great_after_a... ). All of those choices fail your "elegan…

>JSON doesn't have comments so it's a bad choice for human-editable config (...) What about Lua tables?

I second this, I love using Lua tables as a data description language.

Re: The Collapse of the Unix Philosophy

#596

Post by shakna »

gens wrote: post #474
sowhatquestion wrote: post #363

Earlier quoted context omitted.

> It always amazed me when someone looks at computer systems of the 70's through the lens of "today's" technology and then projects a failure of imagination on the part of those engineers back in the 70's True enough, but as a younger programmer, I find it pretty reasonable to look back at computer systems of the 70s and wonder if we can do better today . I feel a little bit gross every time I have to write a bash sh…

>True enough, but as a younger programmer, I find it pretty reasonable to look back at computer systems of the 70s and wonder if we can do better today. I feel a little bit gross every time I have to write a bash shell script (or edit config files that aren't JSON/XML/YAML, for that matter), and I don't think that's a bad impulse. That something so inelegant and unsafe is still in widespread use in 2017 really ought…

This might sound odd.

Instead of writing bash scripts, learn awk.

Awk is old, much older than bash, and has largely gone unchanged since '89.

But, despite the fact it was born in an era where we were still nailing down PLT and what was important in a language, it ticks a lot of boxes.

Having written some sizeable (5000+ LOC) programs in it, it kind of feels like a dynamic mash up of C, and Lisp.

Try Awk, and see if quick scripts are still as painful.

Re: The Collapse of the Unix Philosophy

#597

Post by int_19h »

webmaven wrote: post #593
int_19h wrote: post #592

Earlier quoted context omitted.

> It is probably a bad idea to allow mixed character-set filenames As someone who would be affected by this directly, I can tell you right away this rule would be a no-go. I plainly need the ability to mix Latin and Cyrillic characters in my filenames. A filesystem or OS that wouldn't let me do so wouldn't even be considered. A very simple rule of thumb is, if it is a title of a book (or a song, or a film etc), it sh…

Interesting. Are those filenames used in contexts where homographs could be more than a minor annoyance?

I guess? If a malicious attacker could gain access to my FS and create homographs, figuring out which is which while browsing the filesystem would be non-trivial.

But I find it an unlikely attack vector to begin with. The main concern with homographs is in URLs and other external resources.

Re: The Collapse of the Unix Philosophy

#599

Post by int_19h »

webmaven wrote: post #593
int_19h wrote: post #592

Earlier quoted context omitted.

> It is probably a bad idea to allow mixed character-set filenames As someone who would be affected by this directly, I can tell you right away this rule would be a no-go. I plainly need the ability to mix Latin and Cyrillic characters in my filenames. A filesystem or OS that wouldn't let me do so wouldn't even be considered. A very simple rule of thumb is, if it is a title of a book (or a song, or a film etc), it sh…

Interesting. Are those filenames used in contexts where homographs could be more than a minor annoyance?

BTW, whether a character is or isn't a homograph depends very much on the font. For example, Cyrillic letter 'и' has no obvious visual counterpart in Latin... but as soon as you use cursive, it becomes 'и'. Which is visually indistinguishable from cursive 'u': 'u'.

Same thing with the letter 'т': in cursive, it becomes 'т', which in many (but not all) fonts looks the same as cursive 'm'.

Re: The Collapse of the Unix Philosophy

#600

Post by Const-me »

rwallace wrote: post #465
Const-me wrote: post #159

My favorite one “everything is a file”. My GPU has 4 times as many transistors as my CPU, and for parallel tasks, it computes stuff 50 times faster. Just too much complexity for a file, even with ioctl. I think that ideology is the main reason for the current state of 3D graphics in nix and bsd based platforms.

I didn't downvote you, but I'm not seeing the problem here. It's great that we have these fantastically powerful GPUs, which of course don't use text files as their internal representation, but then we have to tell them what to render or otherwise compute, and very often some form of text file is the most effective way to do that.

Very often, the majority of GPU IO traffic is textures. No form of text file is the most effective representation for them.

However, in my comment I didn’t meant text files. I meant that in *nix, a GPU itself is a single file, /dev/dri/cardN. All that GPU’s complexity is squeezed into a single ioctl system call for that special file. The approach is IMO one of the reason why Linux still doesn’t have reliable 3D acceleration support.

Here’s a long article why Linux ain’t ready for desktops, note the author listed 3D acceleration on the top:

https://itvision.altervista.org/why.linux.is.not.ready.for.t...

Post reply on HN