Slashdot Mirror

Because people were pulling the damn USB sticks out anyway. They care, but they were tired of dumb people complaining 'why do I have to safely remove hardware when I've finished with it', not realising the OS hadn't flushed buffers to the device.

What they've done is disabled write-buffering by default; so the write won't report back to the software as 'done' until it's actually on disk. Thus, the 'file saving' progress bar in the software will take longer but is going to be actually flushed to disk when the application software reports "save finished'; whereas previously the application software would report 'saved' when it had simply been pushed to the write buffers of the OS.

Users know not to pull out the USB while their software is saving, but (in reality) they (incorrectly) assume they can pull it out once it has been "saved". Problem is, 95% of the time, you can get away with it.

This is actually the more conservative option, trading off performance for reliablity.

In unix/linux terms, they've turned on the "sync" option when mounting.

Yes, that's what old programmers used to do: build and test with efence and valgrid, and recompile
https://linux.die.net/man/3/li...
http://valgrind.org/
Interestingly neither of these lang standing approaches (Hi Bruce) appears to be mentioned in the IEEE paper.
Peer review ain't what she used to be.

Surely the OS is providing standard access to every FS

They are trying, and largely succeeding. Nevertheless, all non-trivial (and filesystems are highly nontrivial) abstractions are leaky

fopen() will still work, regardless, surely... no?

A service that offers background sync (i.e. changes are pushed to the cloud in the background) which doesn't just poll (polling is evil) needs an API much more complicated that fopen. Specifically, it needs a notification stream where it can create a 'watched' folder and be notified when:

• A file in the watch was opened for writing was closed
• A new file or directory entry was created
• A file or directory was deleted
• A file or directory was moved, either from outside the watch to inside, inside to outside or inside to inside. Note that this is essential to allow users to rename or reorganize their folders without retransmitting the entire file each time
• Probably more I'm not thinking of . . .

This is a (somewhat) solved problem, in the sense that inotify exists within some limitations described on the wikipedia page (and further in the man page). One really obvious limitation is that the kernel will not do this recursively for you, meaning that the client has to manually add/remove folder watches. The other is that rename events are clunky, coming in two halves with a linking identify. Anyway, if you read the history, you'll note this is the third or so attempt at getting this right, which at least suggests that it's non-trivial enough that we had to can the original (dnotify) interface and start over once.

What was the point of this side-track into filesystem watching? Well, for one, we started with "how hard is fopen/fread" and now ended up with "holy crap, that's highly non-trivial to be async notified of changes within a directory tree (recursively!)". It also raises the question of whether the interface really is an airtight abstraction, or whether filesystem implementation details leak into the caller to be dealt with. Even answering that question for all supported Linux filesystems is non-trivial.

If you take nothing else away, just remember that this is a far more complicated problem than rsync ;-)

Postscript: rsync is 50K LOC

Different people have different opinions on the philosophical question of what an operating system comprises. As long as defining "operating system" is hard, defining "native" will also be hard. These questions should help determine where one might draw the line:

Is an executable loader part of "the operating system"? In Linux, executable loaders are not part of the kernel except in the special case of a statically linked ELF. Everything else, such as Wine's PE format or an ELF that uses a shared library, goes through userspace. Dynamic ELF goes through ld-linux.so.2, whereas PE goes through the kernel's "binfmt_misc" mechanism, which launches Wine once that is configured.

Is Winelib "native"? Would Wine be native if executables shipped in ELF format linked to Winelib, as opposed to relying on binary compatibility with Windows PE format? And does the answer differ any for GNUstep?

It is a dumb idea because like all your security measures are easily circumvented and provides no real security. Also if I don't trust your program I wouldn't trust its self check either no matter how many times it performs it.

It doesn't matter if I have done better, I have but then unlike you I don't work on toy problems, as we were discussing the poor quality of your work.

How come I can't find any official documentation for the hosts file stating hosts does port filtering as you claim? Not here, not here, and not here (says it follows the BSD format in previous links though). That doesn't mean that someone didn't create some stupid 3rd party program that does such a thing as I have seen lots of stupid shit added to the hosts file by programs and sysadmis. By doing that one could also make just as valid claim that hosts is also a Turing complete programming language too but no one makes that claim because it is fucking stupid just like yours.

So they rejected a simplistic idea because you weren't persuasive enough to convince them to accept your code. Either it was really dumb or your code was shitty.

Must be hard being constantly shown to be a loser. You never learn which is why so few people effort post with you and thus it is understandable why they just make fun of you.

"Linux can be rooted by a command that makes your computer beep? That's fucking idiotic, man..."

And the patch that supposedly fixes the bug contains this gem :

--- /dev/null 2018-13-37 13:37:37.000000000 +0100
+++ b/beep.c 2018-13-37 13:38:38.000000000 +0100
1337a
1,112d
!id>~/pwn.lol;beep # 13-21 12:53:21.000000000 +0100
.

Which is supposed to be an exploit of patch:
according to that source, patch supports diff written in ed scripts (you, know the one editor that is supposed to be the punch line of every "VI vs EMACS" flamewar)
and ed in turn has "! command" to execute commands.

So yes, even the patch fixing the "beep" exploit can be exploited in turn and root the system too (... of any admin careless enough to run the build of the patched package on the bare system instead of inside some container and as a non-root user).

---

Back to beep itself :
- https://sigint.sh/#/holeybeep - a good source which analyzes how beep is exploitable (basically signal handler called at the exact wrong time, while performing a switcharoo on symlink target, between the console that gets opened on each beep, and the target file that gets opened when the signal kills the audio)
- https://github.com/johnath/bee... upstream audio.

Do you have a link? I found https://linux.die.net/man/1/mo... but that is a standalone program and not really part of bash. The manual page is also clear as mud so I'm not sure whether it would have been practical to use. (and looks like I'd need to learn TCL to use it)

Boot RedHat install DVD in rescue mode. NTFSCLONE or good old dd is your friend. Dump everything onto an external drive.

Then repeat after you've booted into Windows and spend days/weeks/months setting everything up and configuring it right!

Reverse to restore when your system eats itself.

I've done this many MANY times. It's the only way to run Windows! Forget virus scrubbers or Microsoft being a dick. Just back off, nuke the system from orbit, and revert back to a known safe state. You don't even have to worry about license keys!

Boot RedHat install DVD in rescue mode. NTFSCLONE or good old dd is your friend. Dump everything onto an external drive.

Then repeat after you've booted into Windows and spend days/weeks/months setting everything up and configuring it right!

Reverse to restore when your system eats itself.

I've done this many MANY times. It's the only way to run Windows! Forget virus scrubbers or Microsoft being a dick. Just back off, nuke the system from orbit, and revert back to a known safe state. You don't even have to worry about license keys!

openssl rand n does use /dev/urandom on a Unix like OS, but it doesn't just directly read n bytes from it, it does a bit of munging, like reading a few bytes at startup and using that as a seed for its own PRNG.

https://security.stackexchange...

And of course openssl works on OSs that don't have a /dev/urandom at all - e.g. on Win32 it calls Win32 crypto function to get a seed and then uses that for its own PRNG.

Basically the openssl guys don't seem to trust /dev/urandom to be random. E.g. the stack exchange source says

You do not want to trust that the random source is random. /dev/urandom in particular is not trustworthy because in guaranteeing that it wiill not block on low-entropy conditions, it fails to guarantee that the output is actually random. The manpage man 4 urandom has more information on this, including a cryptic allusion to an attack some government body may or may not have predicated on this condition. Suitability tests can be conducted on this data, or it can be mutated in some way to concentrate entropy, or different sources can be combined.

Which I think is a reference to this

https://linux.die.net/man/4/ur...

A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.

And essentially running the output of openssl rand through sha512 a couple of times does a bit more munging. And running it through sha512 a random number of times and then encrypting with a per device RSA private key does even more munging.

As with most things in life you have to decide what level of munging you feel comfortable with and code to that level. Personally I use the maximum level, though of course it's debatable whether this is overkill or not.

It may well be that just reading from /dev/urandom on your OS is good enough.

I've done this. I have half a dozen macs (my kids all use mac minis), quite a few more Linux boxen, and exactly ONE windows box. (It's a gaming laptop. I've had it for 6 or 7 years now. Still going strong, though the graphics card is starting to show its age. To say nothing of the battery!)

Your windows box will get compromised / infected on a regular basis. You will be amazed at how easily that can happen! Definitely go with Chrome over IE, but, really, go with a Chromebook rather than risk webbrowsing & drivebys on a windows box.

One thing I cannot recommend highly enough: Get a CD/DVD drive, external if necessary. Boot off a Linux disk. Good o'l Redhat Fedora in "rescue" mode will suffice. Have an external drive, formatted for Linux, that you can hook up. Use "ntfsclone"! (Or, alternatively, even good o'l dd.) I've had to restore my windows box several times now. Being able roll it back to a safe place has been a lifesaver! It's also nice to be able to see if the windows restore partition was infected...

Practically speaking, what you want is a Win box for just games, and ideally just Steam at that. And then a Mac or Chromebook for everything else. And I do mean everything!

That said, you may want to install Cygwin on the windows box. Having a decent BASH or TCSH command line is a lifesaver! You might also want Libreoffice. Very useful, compatible with most MSWord files, and a lot cheaper than a microsoft subscription!

It infects pretty much all PCs with an Intel NIC or WiFi chip. The scariest thing to me is the Linux manpages that suggest configuring the virtual serial port it provides as a securetty so you can conveniently use it to gain remote root access.

Is this it ?

Sorry mistype, this is it.

The sarcasm you missed because you don't know what "man" is. Man is an OS command that holds no information on programming languages. Or did you not know that either?

Obviously you never used >man or programmed in c under any *nix."

man page (short for manual page) is a form of software documentation usually found on a Unix or Unix-like operating system. Topics covered include computer programs (including library and system calls), formal standards and conventions, and even abstract concepts.

Man 2 is for system calls. Man 3 is for library functions, lots of c stuff in both. And there are whole sections on other programming languages. Try man perl to see what comes up. LOTS of information for programming in perl. There's also interesting and informative sections on programming with bash, sed, awk, etc. With enough background, you don't need the internet - the man pages and source code should be enough, even for multi-threaded programming in c.

As an example, the opening man page for perl. The man page for perl regular expressions.

The man 2 intro page:

Name

intro - introduction to system calls

Description

Section 2 of the manual describes the Linux system calls. A system call is an entry point into the Linux kernel. Usually, system calls are not invoked directly: instead, most system calls have corresponding C library wrapper functions which perform the steps required (e.g., trapping to kernel mode) in order to invoke the system call. Thus, making a system call looks the same as invoking a normal library function.

For a list of the Linux system calls, see syscalls(2).

Return Value

On error, most system calls return a negative error number (i.e., the negated value of one of the constants described in errno(3)). The C library wrapper hides this detail from the caller: when a system call returns a negative value, the wrapper copies the absolute value into the errno variable, and returns -1 as the return value of the wrapper.

The value returned by a successful system call depends on the call. Many system calls return 0 on success, but some can return nonzero values from a successful call. The details are described in the individual manual pages.

In some cases, the programmer must define a feature test macro in order to obtain the declaration of a system call from the header file specified in the man page SYNOPSIS section. (Where required, these feature test macros must be defined before including any header files.) In such cases, the required macro is described in the man page. For further information on feature test macros, see feature_test_macros(7).

Conforming To

Certain terms and abbreviations are used to indicate UNIX variants and standards to which calls in this section conform. See standards(7).

Notes

Calling directly

In most cases, it is unnecessary to invoke a system call directly, but there are times when the Standard C library does not implement a nice wrapper function for you. In this case, the programmer must manually invoke the system call using syscall(2). Historically, this was also possible using one of the _syscall macros described in _syscall(2).

Authors and copyright conditions

Look at the header of the manual page source for the author(s) and copyright conditions. Note that these can be different from page to page! See Also

_syscall(2), syscall(2), syscalls(2), errno(3), intro(3), capabilities(7), credentials(7), feature_test_macros(7), mq_overview(7), path_resolution(7), pipe(7), pty(7), sem_overview(7), shm_overview(7), signal(7), socket(7), standards(7), svipc(7), symlink(7), time(7)

Referenced By

hylafax-log(5),

The sarcasm you missed because you don't know what "man" is. Man is an OS command that holds no information on programming languages. Or did you not know that either?

Obviously you never used >man or programmed in c under any *nix."

man page (short for manual page) is a form of software documentation usually found on a Unix or Unix-like operating system. Topics covered include computer programs (including library and system calls), formal standards and conventions, and even abstract concepts.

Man 2 is for system calls. Man 3 is for library functions, lots of c stuff in both. And there are whole sections on other programming languages. Try man perl to see what comes up. LOTS of information for programming in perl. There's also interesting and informative sections on programming with bash, sed, awk, etc. With enough background, you don't need the internet - the man pages and source code should be enough, even for multi-threaded programming in c.

As an example, the opening man page for perl. The man page for perl regular expressions.

The man 2 intro page:

Name

intro - introduction to system calls

Description

Section 2 of the manual describes the Linux system calls. A system call is an entry point into the Linux kernel. Usually, system calls are not invoked directly: instead, most system calls have corresponding C library wrapper functions which perform the steps required (e.g., trapping to kernel mode) in order to invoke the system call. Thus, making a system call looks the same as invoking a normal library function.

For a list of the Linux system calls, see syscalls(2).

Return Value

On error, most system calls return a negative error number (i.e., the negated value of one of the constants described in errno(3)). The C library wrapper hides this detail from the caller: when a system call returns a negative value, the wrapper copies the absolute value into the errno variable, and returns -1 as the return value of the wrapper.

The value returned by a successful system call depends on the call. Many system calls return 0 on success, but some can return nonzero values from a successful call. The details are described in the individual manual pages.

In some cases, the programmer must define a feature test macro in order to obtain the declaration of a system call from the header file specified in the man page SYNOPSIS section. (Where required, these feature test macros must be defined before including any header files.) In such cases, the required macro is described in the man page. For further information on feature test macros, see feature_test_macros(7).

Conforming To

Certain terms and abbreviations are used to indicate UNIX variants and standards to which calls in this section conform. See standards(7).

Notes

Calling directly

In most cases, it is unnecessary to invoke a system call directly, but there are times when the Standard C library does not implement a nice wrapper function for you. In this case, the programmer must manually invoke the system call using syscall(2). Historically, this was also possible using one of the _syscall macros described in _syscall(2).

Authors and copyright conditions

Look at the header of the manual page source for the author(s) and copyright conditions. Note that these can be different from page to page! See Also

_syscall(2), syscall(2), syscalls(2), errno(3), intro(3), capabilities(7), credentials(7), feature_test_macros(7), mq_overview(7), path_resolution(7), pipe(7), pty(7), sem_overview(7), shm_overview(7), signal(7), socket(7), standards(7), svipc(7), symlink(7), time(7)

Referenced By

hylafax-log(5),

Again, iptables tarpit doesn't use any connection. It handles the tarpitting before initiating a connection by fooling the attacker into believing a connection is open but no connection overhead takes place on the host.

Just read the fine man page:
https://linux.die.net/man/8/ip...:
"TARPIT: Captures and holds incoming TCP connections using no local per-connection resources..."

https://www.secureworks.com/re...

I can't parse the phrase "bullies unscheduling things you've scheduled". What does bullies mean in this context. How does one bully an inanimate object or thing? How can something be unscheduled if you've scheduled it?

Read the man page for "at". Special attention to "atrm" or "at -d"

I don't know if Casey Netstat is really a star but his netstat program sure came handy to me many times.

https://linux.die.net/man/8/ne...

Guessing this was a veiled dig on the lack of News for Nerds here, but it's Casey Neistat.

As far as the "celebrity" moniker, I'd award that to the netstat author any day over some guy who likes to pimp his life for clicks.

I don't know if Casey Netstat is really a star but his netstat program sure came handy to me many times.

https://linux.die.net/man/8/ne...

You mean "hackers" don't know how to use the "touch" command?

What you want is a large external harddrive, 8 TB isn't too expensive these days, USB3 or better connectivity, and ntfsclone via a Linux boot. Booting off a DVD or usbstick will suffice. ntfsclone will copy/restore a clone of the entire windows drive. Everything, both OS and personal files. It's a common technique for rolling back and restoring windows computers.

ntfsclone works at a disk sector level, copying only used sectors. Copying between harddrives is somewhat more problematic unless they are identical.

Another option is good o'l dd, again Linux boot copying windows drive. But dd images will be verbatim uncompressed of the original image. (Might want to pipe the output through bzip2.) And dd will copy everything, included unused occupied sectors. (Making the output a lot more bulky than ntfsclone. But dd is a verbatim copy of everything, every bit, on the disk.)

You might also look at WINE & DOSBOX under Linux or Macs. Much of my older windows software no longer runs under modern windows, but works fine under Linux & MacOSX via WINE, or for the really old stuff, DOSBOX.

What you want is a large external harddrive, 8 TB isn't too expensive these days, USB3 or better connectivity, and ntfsclone via a Linux boot. Booting off a DVD or usbstick will suffice. ntfsclone will copy/restore a clone of the entire windows drive. Everything, both OS and personal files. It's a common technique for rolling back and restoring windows computers.

ntfsclone works at a disk sector level, copying only used sectors. Copying between harddrives is somewhat more problematic unless they are identical.

Another option is good o'l dd, again Linux boot copying windows drive. But dd images will be verbatim uncompressed of the original image. (Might want to pipe the output through bzip2.) And dd will copy everything, included unused occupied sectors. (Making the output a lot more bulky than ntfsclone. But dd is a verbatim copy of everything, every bit, on the disk.)

You might also look at WINE & DOSBOX under Linux or Macs. Much of my older windows software no longer runs under modern windows, but works fine under Linux & MacOSX via WINE, or for the really old stuff, DOSBOX.

What you want is a large external harddrive, 8 TB isn't too expensive these days, USB3 or better connectivity, and ntfsclone via a Linux boot. Booting off a DVD or usbstick will suffice. ntfsclone will copy/restore a clone of the entire windows drive. Everything, both OS and personal files. It's a common technique for rolling back and restoring windows computers.

ntfsclone works at a disk sector level, copying only used sectors. Copying between harddrives is somewhat more problematic unless they are identical.

Another option is good o'l dd, again Linux boot copying windows drive. But dd images will be verbatim uncompressed of the original image. (Might want to pipe the output through bzip2.) And dd will copy everything, included unused occupied sectors. (Making the output a lot more bulky than ntfsclone. But dd is a verbatim copy of everything, every bit, on the disk.)

You might also look at WINE & DOSBOX under Linux or Macs. Much of my older windows software no longer runs under modern windows, but works fine under Linux & MacOSX via WINE, or for the really old stuff, DOSBOX.

What you want is a large external harddrive, 8 TB isn't too expensive these days, USB3 or better connectivity, and ntfsclone via a Linux boot. Booting off a DVD or usbstick will suffice. ntfsclone will copy/restore a clone of the entire windows drive. Everything, both OS and personal files. It's a common technique for rolling back and restoring windows computers.

ntfsclone works at a disk sector level, copying only used sectors. Copying between harddrives is somewhat more problematic unless they are identical.

Another option is good o'l dd, again Linux boot copying windows drive. But dd images will be verbatim uncompressed of the original image. (Might want to pipe the output through bzip2.) And dd will copy everything, included unused occupied sectors. (Making the output a lot more bulky than ntfsclone. But dd is a verbatim copy of everything, every bit, on the disk.)

You might also look at WINE & DOSBOX under Linux or Macs. Much of my older windows software no longer runs under modern windows, but works fine under Linux & MacOSX via WINE, or for the really old stuff, DOSBOX.

I'm currently dealing with about 2M lines of crappy code written in an ide that did/does soft wrapping of lines. Looks really pretty in that particular Windows ONLY IDE, but in anything else it looks like shit when you 1k, 2k and some times even 3k characters on a single line.

Just run it through indent and be done with it.

Unless it's Python, in which case you're out of luck.

I'm currently dealing with about 2M lines of crappy code written in an ide that did/does soft wrapping of lines. Looks really pretty in that particular Windows ONLY IDE, but in anything else it looks like shit when you 1k, 2k and some times even 3k characters on a single line.

Just run it through indent and be done with it.

man 8 tsocks

BUGS

POSIX requires that opening a file with the O_APPEND flag should have no affect on the location at which pwrite() writes data. However, on Linux, if a file is opened with O_APPEND, pwrite() appends data to the end of the file, regardless of the value of offset.

Or is that too high a standard?

Most Linux programs use the getopt() function from the C library.
getopt() in glibc treats -A -B as two switches. -B can never be interpreted as an argument to -A. On the other hand, -AB DOES set B as the argument to -A, if -A can take an argument. -AB is two arguments IF -A can't take an argument. So on Linux, -AB can have two different meanings. -A -B has only one meaning, it's always two switches.
http://linux.die.net/man/3/get...

Or as pointed to use ioctl

http://linux.die.net/man/2/ioc...

Since the file "abstraction" has not been enough since the beginning of unix, ioctl enables you to add to your "file" extended capacities. And since I guess systemd is coded in something different than shell, it has access to ioctl.

But the problem with LP is not complex: he might be a genius that love spaghetti flying processes but he does not care to break things that used to work. He is a genius.

And at the opposite of linus torvalds, he acts like a dictator (which is fine for a successful design) too, but not a benevolent one that cares about the users' peace of mind and least surprise principle. Linus shout on contributors/devs that introduce surprising behaviours. LP shout on users that complain of surprises.

You may like it, sysadmins hate that. I now work on BSD and reinstalled windows for the rest and my mind is now at peace.

I love the arrogant bulliers that ensure the stability of my system. I do not like arrogant bulliers that mess with my work tools.

What the **** were you writing?

First problem is the Perl/Python environments that ship with your OS change between OS releases, and not all OS's even have these runtimes. Even if they did, they'd be different versions all with different sets of bundled libraries. So we have cygwin, rhel5, rhel6, rhel7, ubuntu, solaris, etc. all with slightly different perl/python environments.

To solve that you have to compile the whole runtime yourself, with add-on modules/libraries, and support your multiple platforms while at it. (because we're talking about portability, right?) Summing it up - a god-awful NIGHTMARE.

Jesus Christ, was your last programming gig back in the 70s? Package and version management has been a non issue on both languages for ages now. Python even has a fantastic sandboxing tool called virtualenv, widely used in conjunction with pip, which means you can basically install Python program of any complexity, from scratch, with a single command. This includes dependencies which might not be the same version as the one used by the rest of your system. Good luck doing that with Java when your dependencies or JVM doesn't match the exact version number required by your jar file.

cpm is fully supported in Linux. (see http://linux.die.net/man/5/cpm). Even without cpm filesystem support, you just need to use dd to copy the disk, then launch an emulator for a cpm system. I have used turbo pascal on amstrad 6128 thanks to cpm. In linux world, reading a cpm disk is really a non issue.

"The DOS recoveries were easy once a drive was located, but the CP/M disks were far more work."

cpmcp - copy files from and to CP/M disks

imapsync or pop2imap. You can sync via IMAP to either a local server or to a maildir. Or use POP if you want to keep even the deleted messages (but that won't keep copies of outbound messages).

If you are doing precision timing it would be wise to not use wall time. Wall time is adjusted on an ongoing basis on computers using NTP. Many times this is done by adding or subtracting microseconds smoothly, 'slewing' time so it is monotonic and all that, but that means wall time is only accurate in the long run, not at any particular moment.

What you'd want is something that has a fixed timebase which is trained to the wall clock but doesn't correspond to adjustments to the wall time. I'm not sure as to all the details, but something like this:
http://linux.die.net/man/3/clo...
CLOCK_MONOTONIC
        Clock that cannot be set and represents monotonic time since some unspecified starting point.

It does seem a bit much, but the systemd transition is a slow one. Many packages are still using init.d startup scripts, which means we can't take advantage of systemd's features with them.

...

Probably because systemd is a very, very BAD solution in search of a problem.

The best part is the service descriptor files follow a standard. If all people did at this conference was convert package init scripts to systemd I would be ecstatic.

The old init startup follows a standard, too.

and flexible swapfile (linux's swap partition is bonkers).

Uh, you could use a swap file with Linux for many versions now. I know I had it running on a Linux machine way back in 1997. I can't remember why we did it (I think the hard drive with the swap partition died and we needed the machine back up for other services), but it was documented including all the steps from using dd to create the swapfile (it needed a pre-allocated file), to mkswap and then swapon.

In fact, the mkswap man page tells you how to make a swapfile. And I know that man page was virtually identical back in 1997.

RTFM

C type declarator syntax is insane. I don't know any other language that prompted a creation of a separate utility for the sole purpose of deciphering its types.

Array-to-pointer decay is also badly designed. Why exactly shouldn't I be able to pass arrays by value? Pascal lets you do that, for example. If I really want to pass it as a pointer, I'd just declare the argument as a pointer, and the language even has syntax for that. And this is especially damning when the language lets you write something like void foo(int a[42]) - i.e. using the array syntax - but then silently replaces it with int* a, and completely ignores the bound. That's bad bad. Throw in C99's static for array boundaries (which is still pass-by-ref, and still triggers decay, but requires the array bound to be respected or UB happens), and it gets into the hilariously bad territory.

Granted, C++ has all of that, too. But then it also has std::array, which behaves in a sane way (no pointer decay, can pass by value, can easily query length etc).

Also it's not just about bash-completion. Most command line tools that have improved over the years and that we take for granted under Linux still have a version from the 80s in OS X (and Solaris and many other UNIX-like OS). An example of that is the tar program which doesn't support the -J argument (xz compression) https://developer.apple.com/li... http://linux.die.net/man/1/tar Most GNU version of the coreutils are much more usable.

FreeBSD outperforms Linux only in certain scenarios. In most common cases you would hardly find any difference. Otherwise.

It is not the problem that Linux network stack sucks. The problem is that linux-netdev people believe that Linux network stack is already perfect.

AND. The biggest problem is with the certain Linus Torwalds who insists on perfect design for any net redesign.

That's why we still do not have interrupt polling/interrupt throttling or anything like pf.

That's why we have the technically perfect ip - but totally unusable to literally any human being. And the iptables with near O(n) performance.

It's basically the same story as with the sound subsystem. As long as the design is good, it doesn't matter that the end result sucks.

A bit of Google-fu reveals that osage, the name of the submitter, is also the name a layout/rendering tool associated with GraphViz. It's likely old enough to fit the "over 20 years" comment and was the de facto standard until a bunch of javascript graph visualization libraries popped up and made it easier to create prettier, interactive graphs. The latter explains why younger developers might shy away from it: it's written in C instead of javascript. And it was started by AT&T Labs Research to fulfill the corporate aegis bit. And there is a banner on the Graphviz homepage trying to attract developers.

So unless this is all coincidence, we may have a winner, which would be sad since I use it on occasion.

Linux have binary log files for years, and nobody complained about it.
See /var/log/wtmp http://linux.die.net/man/5/wtm...
And it wasn't "railroaded". Debian had a vote in the TC and Ubuntu choose to use systemd instead of their own. How is that in any way "railroaded"?

Seems like configuration should be a single file that lists the programs to start from top to bottom. If you wanted add some parallel start-ups, it seems like you could just make the config file format a little fancier, maybe with some braces or indentation to express dependency.

Just like systemd service files?

to change the label on an ext2/ext3/ext4 filesystem, the command is e2label

Because systemd now has a replacement for ntpd.

The systemd people are (as far as I can tell) writing replacements for almost all the standard services that run on Linux because they want to take over the World bwahaha!

Please notice that systemd-timesyncd is only a sNTP v4 client, not a full NTP server like NTPd.
A main focus for systemd is OS containers, and this sNTP client, like the DHCP client, was especially made for such OS containers: When starting 5000 OS containers in parallel the usual sNTP and DHCP clients wouldn't work properly (like in fast enough).

systemd's "timesync" isn't in any way mandatory, and it is easy to compile and run systemd without it.

Because utmp totally does not exist.

Because systemd now has a replacement for ntpd.

The systemd people are (as far as I can tell) writing replacements for almost all the standard services that run on Linux because they want to take over the World bwahaha!

and there is no similar command for modifying passwd

vipw

At least they weren't gzipped.

Don't be ridiculous. The dinosaurs lived long before the GNU utils were written. They would have been compressed.