Slashdot Mirror

Troll troll troll your boat....

Hardly.

The Gnome desktop has become a steaming pile of bloat.

systemd is a shitty, shitty, shitty solution in search of a problem, from the very same sphincter that excreted PulseAudio - one of the same Linux turds that the GP post complained about.

And yeah, Linux has become less stable than Windows. And that's not surprising, given the attitude many in the free software community display towards standards. Hey, if you can't get fork() to be async-signal-safe as the POSIX standard requires, try to get the standards committee to lower the standard so you can meet it.

Because "We don't meet that standard, so would you please lower it even though everyone else does meet the standard?" is not an attitude that leads to stable, robust systems.

The glibc does embed a copy of libidn in the source code and apparently link statically against it: https://sourceware.org/git/?p=... https://sourceware.org/git/?p=...

The glibc does embed a copy of libidn in the source code and apparently link statically against it: https://sourceware.org/git/?p=... https://sourceware.org/git/?p=...

..and verify that all time functions everywhere in the os now continue to give correct values. ...ah, those little things... that nobody that ever spoke like you... knows anything about.... clearly you arent a software developer, and not only that, you dont even fucking know one.

The issue is data types and aliasing not time specific logic. Check out links posted by petermgreen which go into great detail what is necessary.

https://sourceware.org/glibc/w...

Microsoft managed to change time_t to 64-bit due to time_t not being widely used in Windows and because shared libraries on Windows rarely exchange time_t values (since that would break if you linked with an old dll that used the 32-bit time_t as you might imagine).

Stance in Linux land regarding the issue is not to go 64-bit or be abandoned, there are plans in motion, it's just that there are a lot of code to go over and change since time_t is a central piece in Unix vs Windows where it's practically not used anywhere.

GNU libc has this plan: https://sourceware.org/glibc/w...

And the plans for the Linux kernel: https://lwn.net/Articles/64323... . Latest update: https://lwn.net/Articles/71707...

At some point Linux ABI was updated to support files exceeding 2^31 bytes while retaining full backwards compatibility so I I'm not buying insurmountable technical justifications other than simple lack of will.

There does in fact seem to be some progress taking a similar approach to large file suport..

https://sourceware.org/glibc/w...
https://github.com/3adev/y2038
https://gitlab.com/bminor/glib...

If/when it will be completed/merged I do not know.

Which just highlights that the problem is the licensing model.

Yes - that is what you get when you go for commercial software.

Open source is nice. No licencing fees, manufacturers don't meddle in how you use (or resell) the sw, no licence tracking overhead. Lower TCO, and the overall quality is better too. Finally, there are fewer ads involved!

And when the feds come knocking about your home-grown open source solution, how do you plan on PROVING that you are Sarbanes-Oxley or HIPAA compliant?

Or maybe you find a fundamental bug in this open-source solution with no work-around, and the developers decide they're not going to fix it, even though it's a violation of the POSIX standard, and no other implementation fails to meet the standard...

Looks like this is the end of Sun SPARC and Solaris.

Good riddance if you ask me, it was getting quite antiquated relative to Linux. Now we just need to kill off AIX. Hopefully everyone will standardize around Linux and BSD.

Call me when fork() on Linux is async-signal-safe, or when Linux's `pwrite()` isn't borked (read the "Bugs" section on the man page...)

See this on Linux fork() being broken: https://sourceware.org/bugzilla/show_bug.cgi?id=4737

That bug report is 10 years old.

The Linux solution? Attempt get fork() removed from the POSIX standard as being required to be async-signal-safe.

See GLIBC bug 4737 - "WONTFIX" == "too hard"

I guess POSIX is too high a standard for Linux to be held to?

Nevermind systemd....

Looks like this is the end of Sun SPARC and Solaris.

Good riddance if you ask me, it was getting quite antiquated relative to Linux. Now we just need to kill off AIX. Hopefully everyone will standardize around Linux and BSD.

Call me when fork() on Linux is async-signal-safe, or when Linux's `pwrite()` isn't borked (read the "Bugs" section on the man page...)

See this on Linux fork() being broken: https://sourceware.org/bugzilla/show_bug.cgi?id=4737

That bug report is 10 years old.

The Linux solution? Attempt get fork() removed from the POSIX standard as being required to be async-signal-safe.

See GLIBC bug 4737 - "WONTFIX" == "too hard"

I guess POSIX is too high a standard for Linux to be held to?

Nevermind systemd....

Um - https://libreboot.org/

Also there is more information as to why libreboot left the GNU. From their site - 'Libreboot left GNU on 2016-09-15, in protest of transgender discrimination at the FSF'.

Not surprising.

FSF is pretty close-minded - "my way is always right!"

It even includes technical issues, too. Glibc fork() is not async-signal-safe per POSIX? Even though BSD and Solaris and AIX have no problem making fork() asynch-signal-safe, GNU folks go with "WONTFIX" and try to lobby to water down the POSIX standard because it sets too high a bar for them.

"Great for old hardware" is a myth at best, and sometimes a farce.

Myth example: I had an old Pentium III 650 Mhz machine with 256 MB of ram. It was consuming more power than my AMD Athlon 2.0 Ghz with dual core and 4 GB of ram. I have the same story with a bunch of old IDE 80 GB drives. I could string together 12 of them in a JOBD to get 1 TB, or I could just buy a 1 TB drive. At some point you have diminishing returns on that old hardware.

Farce example: GCC was generating the CMOV instruction for 486, even though cmov was first invented on 586. Obviously, no one was using that old hardware, or their programs would have all crashed. (I think this is the thread. https://sourceware.org/ml/libc-alpha/2004-09/msg00157.html)

I used to think that too, but then I learned assemblers and even machine code can have bugs. Now I write all my software on the cloud!

Agreed that CUDA and OpenCL are great secondary and tertiary ways of heterogeneous multi-core programming.

Not sure what your beef again OpenMP is. OpenMP makes it trivial to add multi-threading to your app.

When did C++ get thread control again? Oh yeah, it wasn't until C++11 and you STILL had to wait for compilers to implement it. In the mean-time OpenMP was already here, and working for years. Considering OpenMP has been around for 18 years, calling it a hack when C++ ignored the whole standardization of multi-threading for YEARS is pretty fucking arrogant -- especially when Intel's, Microsoft's and GCC's compilers have natively supported OpenMP for years. What were Windows users supposed to use in the mean-time for portability? A port of pthreads wasn't even available for Win32 until ~2001 if this page is correct.

There are problems with std::future as this committee paper points out:

* N3964 (March 2014)

Even co-routines are still relatively new:

* N4134 (Oct 2014)

C++11 std::thread is great for the future. OpenMP was a perfectly fine solution when C++ didn't even have one back in the day.
 

A particular sin() implementation by IBM has always looked scary to me. I found it via an interesting Stack Overflow thread which talks about trigonometric functions.

I've read a bit through the threads and think that the reason it took so long was because they decided to remove a feature to fix the problem:

I believe the current plan is to completely remove the transliteration
module support, as it hasn't worked for 10+ years.

The git commit message states the same. There were really some problems in that function: https://sourceware.org/ml/libc...

I chose the word scepticism, and still I think it is. I agree that the word "unexploitable" was a bit exaggerated, but that was added by unknown lamer.

Florian Weimer said:

My assessment is "not exploitable" because it's a NUL byte written into malloc metadata. But Tavis disagrees. He is usually right. And that's why I'm not really sure.

Its however true that he corrects himself the same day a bit later:

>> if not maybe the one byte overflow is still exploitable.
>
> Hmm. How likely is that? It overflows in to malloc metadata, and the
> glibc malloc hardening should catch that these days.

Not necessarily on 32-bit architectures, so I agree with Tavis now, and
we need a CVE.

Is here

You know it's a problem when...

If you were to write a simple python program that uses say, the Panda package, would you include all the lines of code of that package when line counting your program? No.

Yes, as we all know, Hello World in C is actually thousands of lines long. (shakes head sadly) It's a terrible language.

I thought dotless domains were coming, and put full support for dotless domains in SiteTruth.

There was a long discussion of this on the Mozilla developers mailing list. There are some dotless domains right now. A few country codes will resolve to an IP address, and one or two actually have a web site there. Try ac

A lot of software, some of it very low level, mishandles dotless domains. If you look up "ac" in DNS, you'll get a valid IP address. Browsers, though, usually try using it as a search keyword, or try it with ".com" suffixed. There was a concern that if every word typed into a browser's input box had to be checked for being a TLD domain name, it would overload the root servers and delay search responses. DNS TLD "no finds" are relatively expensive operations.

Down at the "getaddrinfo()" level, there's a known bug. There's an exploit for this that drives traffic to subdomains of "com.com", which is set up so that all subdomains of .com.com" are full of ad pages. Right now this is just annoying, but it could be exploited in more ways if single-component domain names became popular. That's really hard to fix, because it's in the C library on most machines. Applications would have to be rebuilt.

If you put a "." at the end of a domain name, it's "rooted", and local lookups on your local network do not apply. Type "ac." into your browser's input box, and you'll get some domain registrar who bought the Ascension Island TLD.

ICANN actually did something right.

Some of the linux subsystems still read like they were written in someone's basement even after a decade of most of the maintainers being paid a yearly salary to maintain it.

What makes you believe that those people paid a yearly salary have moved out of their basements?

I mean, Ulrich Drepper is a rather infamous basement dweller, and he was on RedHat payroll for years.

Just have a look at the printf source code (actually vfprintf). If you don't understand it, that'll remind you your old maths classes ..

It looks to me like most the problems they are solving have already been solved. There are already several open source log-structured file systems. This list excludes experimental and similar software from educational institutions:
      - Yaffs - http://www.yaffs.net/ - designed from the ground up for NAND
      - JFFS2 - http://sourceware.org/jffs2/jffs2-html/jffs2-html.html - ditto.
      - NANDFS - http://wiki.freebsd.org/NAND - BSD style licence

Plus there's Ext4 - which is used in Android now - not designed for NAND, but seems to work ok.

This work by Samsung fixes the problems with their previous file system. It's good, but it's not unique. Good PR though.

The goal is to merge eglibc back into glibc, yes. After the previous glibc steering committee disbanded, it switched to being run by an informal three-person committee, one of whom (Joseph Myers) is also one of the lead maintainers of eglibc, so the two projects' leadership are no longer at odds. And Myers has suggested that the goal is to start moving eglibc changes over into the main glibc branch.

Oh c'mon now, where else can you get such nasty venom? You just gots to love stuff like this where he says ARM is nothing but "embedded crap" How can you NOT like such an arrogant little self important shit? hell he reminds me of little Mickey 500 accounts here, all he needs to do is add "You are pathetic" at the end of each post and he'd have it down pat!

Have you tried one of the following replacements?
http://sourceware.org/systemtap/wiki/SystemtapDtraceComparison

Read http://sourceware.org/bugzilla/show_bug.cgi?id=4980 or http://sourceware.org/bugzilla/show_bug.cgi?id=4403 for a good laugh. /. trolls pale in comparison. :D

Read http://sourceware.org/bugzilla/show_bug.cgi?id=4980 or http://sourceware.org/bugzilla/show_bug.cgi?id=4403 for a good laugh. /. trolls pale in comparison. :D

When people say 'Linux' they usually mean Linux-and-all-of-the-associated-cruft. Typically this at least includes GNU libc, GNU binutils, and GNU coreutils (which, between them, are more code than the kernel), and typically the GNU shell (bash) and GNU libstdc++. All of these have no moved to GPLv3 (in some cases with the runtime exemption).

GNU libc? Not so.

When people say 'Linux' they usually mean Linux-and-all-of-the-associated-cruft. Typically this at least includes GNU libc, GNU binutils, and GNU coreutils (which, between them, are more code than the kernel), and typically the GNU shell (bash) and GNU libstdc++. All of these have no moved to GPLv3 (in some cases with the runtime exemption).

GNU libc? Not so.

Yeah, that's an icky upstream glibc bug, there's a patch submitted upstream: http://sourceware.org/bugzilla/show_bug.cgi?id=13013

But the systemtap devs don't seem overly concerned.

There is one for Classpath called Mauve. I doubt it's 100% comprehensive but it's a start.

I already replied with the one I submitted, but here's another one that I first saw referenced on Slashdot.

https://bugzilla.mozilla.org/show_bug.cgi?id=92165

It's just _PAINFUL_ to read through this bug! It's almost 10 years old now!

And on the topic of crazy bug reports...here's another (non-Mozilla):

http://sourceware.org/bugzilla/show_bug.cgi?id=4980

Yea, I agree with you. All this high-and-mighty attitude, especially from RMS, and now this. I'm glad debian (and thus ubuntu) switched to eglibc, looks like Mr. Drepper did the open source world a huge favor, although this maybe wasn't intended ;)

Will apple try the same carp on iphone unlocks soon?

I'm Ulrich Drepper, and I approve of this message.

http://sourceware.org/bugzilla/show_bug.cgi?id=5070#c1

I don't know how it compares to dtrace (in this wiki it appears that they have feature parity for all the important stuff), but I can tell you that it works quite well and it's very complete and it's well documented. It really deserves the 1.0 version tag.

But in the kernel world very few people seems to use it, it seems that perf + static tracepoints have become the preferred tool for performance diagnostics.

SystemTap

He said he wanted portable. Admittedly you have to recompile for each OS, but that's better than Java's solution (write their own goofy SSL implementation, though it's available on all platforms as OpenSSL, use the platform's Regex library, though it is not consistent in all platforms).

> sockets
Use the MinGW compiler (or cygwin) in windows, alternatively LibSDL has a socket library. I think there are other Berkley Socket libs for Windows.
> IPC
Probably would work with MinGW. Not sure what this is to be honest, though.
> threads
Uise the MinGW compiler (or cygwin) in windows, alternatively LibSDL has a thread library. Also, there is a pthreads implementation in Windows.

I've used Pthreads successfully as a cross-platform threading library. http://sourceware.org/pthreads-win32 is a quite good implementation for Windows, and it's built into Linux (and all other POSIX compatible OS's, such as OS X, as well).

Linux containers provide similar functionality to Solaris Zones: http://lxc.sourceforge.net/ They're a younger project but the support for them is in mainline Linux and you can do some pretty cool stuff with them. One thing that's nice (and I don't know if Zones can do this) is that you don't have to virtualise every aspect of a container, so for instance you can just isolate at the filesystem level if that's all you needed. Solaris Zones is capable of running apps for another OS within a Zone, using their system call compatibility layer. Linux has a system call compatibility layer but I don't know if it can run a complete other-OS userspace as Zones can (e.g. Zones can run CentOS or RHEL userland in a Zone, on top of the Solaris kernel).

Most everyone here is going to have heard of Btrfs but here it is again anyhow: http://btrfs.wiki.kernel.org/index.php/Main_Page It gives you similar stuff (checksumming, RAID-in-filesystem, writeable snapshots) to ZFS but again is a younger project. It's also in mainline Linux so you can play with it if you have a recent kernel (don't trust it with critical data, yet).

System Tap is one (of a number) DTrace-ish system for Linux: http://sourceware.org/systemtap/ I understand it'll run on basically any non-stoneage kernel but to get all of the juicy features you would (I *think*) need to patch your kernel. This is the only one of these projects for which full functionality appears not to be completely in mainline. Various distributions include it, so you can probably install a package and try it out (at least in a limited form, depending on your kernel).

A notable feature here is that none of these sound quite as mature as the Solaris equivalents. Not all of them constitute "copying", however - for instance, container-like solutions for Linux predate Solaris Zones by years (and BSD Jails, a similar concept, are almost certainly even older). I'm not sure on the dates of the others.

The GPL requires source distribution precisely because this is very difficult to do

Difficult? Big fucking deal. The GPL requires source distribution because contracts between software publishers and end users (try to) make this illegal to do.

Whoops, screwed that one up, I meant like this.

That's quite a read, you have to go out of your way to get multiple people writing comments like this one:

"Wow, you are a bastard. I hope you die alone. :D"

Not on the internet you don't.

Oops, I mean

Wow, you are a bastard. I hope you die alone.

He said "embedded carp"

http://sourceware.org/bugzilla/show_bug.cgi?id=5070#c1

Indeed - and not just ordinary, non-involved people. In one bug alone, he managed to upset Gentoo's Mike Frysinger, he told Petr Baudis of SuSE that "I never saw your name on my paycheck. Since if that's not the case you cannot order me around., and gave the MirOS developer Thorsten Glaser cause to comment on Drepper's standards.

Nice going!

Indeed - and not just ordinary, non-involved people. In one bug alone, he managed to upset Gentoo's Mike Frysinger, he told Petr Baudis of SuSE that "I never saw your name on my paycheck. Since if that's not the case you cannot order me around., and gave the MirOS developer Thorsten Glaser cause to comment on Drepper's standards.

Nice going!

Indeed - and not just ordinary, non-involved people. In one bug alone, he managed to upset Gentoo's Mike Frysinger, he told Petr Baudis of SuSE that "I never saw your name on my paycheck. Since if that's not the case you cannot order me around., and gave the MirOS developer Thorsten Glaser cause to comment on Drepper's standards.

Nice going!

I know! For the record, he was talking about the problems of the patch in aquatic environments. "It's working fine everywhere but this carp architectures."

I'm not surprised that the project's been forked after reading this bug. Not only was he wrong, but he was adamantly wrong. It was only when his employer (RedHat) stepped in that it looks like they solved the issue.

Wow, the bug you linked makes this guy look like a GIANT DOUCHE. What an asshole.

That particular comment was in response to something posted by a fake Drepper. Check the email address for comment #40.