Slashdot Mirror

Since this is Larry McVoy I wouldn't be surprised if it is true. A different story, but related:
http://article.gmane.org/gmane.comp.version-control.mercurial.devel/3481

I have seen and accepted many non-free licenses over the years and I'm fine with most of of them. But Larry McVoy and BitKeeper stepped over the line. I will never under any circumstance defend him or his work, his actions have been downright harmful to creation of free software at a lever which is simply unacceptable.

According to a comment on Phoronix ( http://www.phoronix.com/forums... ), the cause is a goto:

"And the funny thing is? The guilty line is a fucking GOTO. Everyone using this atrocious coding practice should be shot in the head." ("magika")

User "stevenc" adds: "It's a pretty common pattern of trying to emulate Objected Oriented Programming in C. Try to construct one or more 'objects', otherwise fall back to one or more 'destructors' at end of the function. They'd even implemented their own reference counters within the struct (object) and had function pointers (methods); both of which allowed this to be an exploitable bug. In OO languages these are implemented in the language/interpreter/compiler and usually done right. "

Now please contrast the desire to have C++ features without using C++ with this post: http://article.gmane.org/gmane...

At least one "substandard" programmer has a lot of egg on his face right now...

The requirement for client credentials in implementations of OAuth produces a couple practical problems.

OAuth 1 and OAuth 2 are unrelated protocols with similar names. The spec for each discourages servers from requiring client credentials (a client ID and client secret) in an API intended for use in an app that runs on the user's computer, such as a desktop or mobile app. As stated in section 4.6 of the OAuth 1 RFC:

In many cases, the client application will be under the control of
potentially untrusted parties. For example, if the client is a
desktop application with freely available source code or an
executable binary, an attacker may be able to download a copy for
analysis. In such cases, attackers will be able to recover the
client credentials.

Likewise section 9 of the OAuth 2 RFC:

Native applications that use the authorization code grant type
SHOULD do so without using client credentials, due to the native
application's inability to keep client credentials confidential.

And the article "OAuth 2 Simplified" by Aaron Parecki states:

If a deployed app cannot keep the secret confidential, such as Javascript or native apps, then the secret is not used.
[...]
mobile apps must also use an OAuth flow that does not require a client secret.

Yet several service providers offering APIs built on OAuth 1 or OAuth 2, notably Twitter, require them. Despite it being trivial to pull client credentials out of an executable with tools such as strings, Twitter has been known to disable any client credentials that leak to the public. There are two workarounds, both cumbersome:

• The first, recommended by OAuth 1 spec author Dick Hardt, is to proxy all API calls through a server that the app developer operates. The API keys then never leave this server. Yet the app developer needs to find some way to recover the cost of operating this proxy server.
• The other, as recommended by Raffi Krikorian and Chris Steipp, requires each user to register with the service provider as a developer, obtain API credentials through the developer console, and enter those into the user's own copy of the application. Because providers tend to refuse to offer a means of automating application registration, each application has to include a walkthrough for registering a copy of an application and update this walkthrough whenever the service provider changes the design of the developer console. In addition, developer consoles tend to require a minimum age of 18 to rather than 13.

OpenID 2.0, an authentication protocol, did not require relying parties to obtain client credentials. It was intended that a user would paste his identifier URI into a form on the relying party's web site (or use a browser extension to autofill it), and the user would be briefly redirected to the identity provider's web site for verification. Very few identity providers required relying parties to register; the only one I could think of was PayPal.

But unlike OpenID 2.0, which was open by default, the OAuth 2-based OpenID Connect is closed by default. It requires each relying party to obtain client credentials from each identity provider's developer console, which requires O(n^2) contract executions. There's theoretically a way for a relying party to obtain client credentials automatically, called Dynamic Client Registration (dyn-reg), but to my knowledge

What about the concatenated case?

Hash1(data) + Hash2(data)

The security here is going to be as strong as the strongest of the two hashes, but not stronger as far as collision resistance goes. As such, there isn't really much point in using the second hash.

For a bit deeper of a read: http://article.gmane.org/gmane...

In particular:

Joux then extended this argument to point out that attempts to increase
the security of hash functions by concatenating the outputs of two
independent functions don't actually increase their theoretical security.
For example, defining H(x) = SHA1(x) || RIPEMD160(x) still gives you only
about 160 bits of strength, not 320 as you might have hoped. The reason
is because you can find a 2^80 multicollision in SHA1 using only 80*2^80
work at most, by the previous paragraph. And among all of these 2^80
values you have a good chance that two of them will collide in RIPEMD160.
So that is the total work to find a collision in the construction.

FYI, gitk does almost everything that sourcetree does, and it's part of the official git source tree.

p.s. Caution: There's a serious bug in gitk that makes gitk almost completely useless for any patch containing angle brackets (apparently nobody else that uses gitk has ever viewed patches containing greater-than or less-than, C++, or XML, so I might actually be the only person on earth that actually uses gitk). Anyway, here's the 2 line super hack I've been using to eliminate the bug on my local machine:

$ git diff --no-index /usr/bin/gitk{.broken,}
diff --git a/usr/bin/gitk.broken b/usr/bin/gitk
index 90764e8..abbfe8a 100755
--- a/usr/bin/gitk.broken
+++ b/usr/bin/gitk
@@ -8074,11 +8074,11 @@ proc parseblobdiffline {ids line} {
        } else {
            $ctext insert end "$line\n" filesep
        }
- } elseif {![string compare -length 3 " >" $line]} {
+ } elseif {0 && ![string compare -length 3 " >" $line]} {
        set $currdiffsubmod ""
        set line [encoding convertfrom $diffencoding $line]
        $ctext insert end "$line\n" dresult
- } elseif {![string compare -length 3 " <" $line]} {
+ } elseif {0 && ![string compare -length 3 " <" $line]} {
        set $currdiffsubmod ""
        set line [encoding convertfrom $diffencoding $line]
        $ctext insert end "$line\n" d0

I'm an occasional writer who's not good enough to go pro, but I have looked at some authoring tools, and haven't found any I like better than several terminal windows running vim.

This book is quite beautiful - produced completely in emacs org mode.

It was even written collaboratively. Export to docx works well enough in emacs org mode using pandoc. There is a discussion here

Welcome to 2012! as it was when compressed memory was introduced in Linux.

Because a lot of security boils down to "I'm thinking of a number between 0 and $something, I bet an attacker can't guess it at a rate better than blind chance".

e.g. a 128 bit encryption key is a number between 0 and 340282366920938463463374607431768211455. With a secure random number generator, an attacker will have to on average test half of those possible keys before he finds the correct one, because he can't know anything that will reduce the space he has to search.

If your random number generator is broken - for an extreme example, say you only seed it with a 16-bit process ID - suddenly the random values you generate are trivially guessable, because there's only 65535 possible streams of randomness to check instead of $impossibly_huge_number. What should have taken longer than the age of the universe to crack now takes mere seconds.

First up lkml.org is a third party site that hosts Linux kernel mailing list archives on a website. Regular Linux kernel mail isn't actually sent from it (I believe that's done by vger) so we're looking up the email reputation for the wrong IP...

Secondly UCEPROTECT is a very aggressive blacklist which states upfront they will block people who they believe are in the vicinity of people who the judge to be sending them spam. It's not the be and end all though and on one server I looked some time ago it's effectiveness was surpassed by other blacklists (here's someone else's old DNS blacklist comparison for 2014). In general I prefer more conservative tools like senderbase when trying to work out an IPs mail reputation.

For what it's worth I've also seen GMail incorrectly mark mails sent to the fio mailing list (which is also managed by vger) as spam and in that case it was purely down to mail being proxied through the list which was a place that didn't match the sender's DMARC records. Most of the time GMail was getting the marking of spam right though (even for mailing list mails)...

What do you think about new "system languages" like Go and Rust? Are they OK in your opinion, or do they suck as much as C++?

This only works if the website gives the ISP their private key. When the relationship between the website and the ISP is short, the website would probably be reluctant to do that.

So I'm not so sure they would do that.

But I agree if they have such a relationship an other way would be for the ISP to have a protocol where the website can get the information they currently put in a the header by requesting the information that goes with an IP/port combination. Just like haproxy/postfix does it:

http://permalink.gmane.org/gma...

But at least nobody else can get this information. For example when it's unencrypted any passive attacker could see the extra header that was added.

Does anyone know why you want encryption directly in the filesystem rather than the layered approach being offered for years by the dm-crypt kernel filesystem? The Phoronix article mentions that is intended for Android systems, so my immidiate thinking was that it had something to do with flash storage specifics. Generally I do not like it when a generic, simple solution like dm-crypt gets reimplemented at another layer, increasing complexity, but maybe there is a reason for this?
Another article mentions F2FS (Flash-Friendly File System) as a possible merge target. Suggests it serves needs for flash memory. I guess exposing the filesystem structure/metadata without actually revealing the data itself makes more efficient flash utilization possible. Or maybe it makes it easier for law enforcement to bypass it, if your tinfoil hat is on.
The mailing list entry itself is here: http://thread.gmane.org/gmane....
Links to a design document in the mailing list was dead at time of writing.

Just from looking the LKML, it appears there were some issues that the usual suspects involving code quality (Linus, Greg K-H) were arguing over. The fun and excitements starts at http://article.gmane.org/gmane....

We can look to the Starks and the Torvalds of this world for the solution to this problem.

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

In the sight of the newsgroup, in the name of software stability and maintainability, I Linus Torvalds, creator and maintainer of linux, creator of git, sentence you to die. You will speak no final word.

All over their mailing list and in redhat's bugzilla. It's the same bug that prevenbts booting with a degraded RAID.

Have a look at this. Complete with Lennart's usual attempt to pencil whip the bug away with a hasty close "notabug" only to have it re-opened. Report created in 2013, still status: assigned two years later.

Then there's this. There is a reliable way to see if a btrfs can be mounted degraded. Try to mount it with -odegraded and see if it works!

That would be easy in a system that didn't implement policy in code.

Not only is this a dupe, it's an out-of-date dupe:

http://article.gmane.org/gmane...

The closest thing to such a quote I can find is this, which is pretty much the opposite of such a statement

What's the bug#?

Is this the same as Chris Murphy | 19 May 02:54 2014
problem with degraded boot and systemd

aka [systemd-devel] timed out waiting for device dev-disk-by\x2duuid

elinks can be compiled with graphics support, allowing you to browse with images in a console as well (need gpm too or a touch screen equivalent).

And doesn't Stallman claim to surf the web via some hackery involving wget and email?

http://article.gmane.org/gmane...

Btrfs RAID5 won't have a write hole. It is fairly equivalent to zfs RAID-Z.

Right now the btrfs raid5 code doesn't recover from any kind of disk failure at all - it is experimental (that is, it writes parity to disk, but cannot use it to recover missing data). All data written to each disk are checksumed, so in the event of a problem during write the filesystem can determine which disks are correct and which ones aren't. Also, like zfs btrfs does not overwrite data in-place, so in the event of a failure files should end up in either the pre-write or post-write state.

I couldn't find any official docs about raid5 on btrfs at all - it is still experimental. Mailing list posts seem to suggest that it will not have the write hole when complete (such as http://comments.gmane.org/gman... ).

Now, I'm talking about btrfs directly writing to disks. If you stick mdadm in-between btrfs and the disks (avoiding the layering violation), then the result will be the same as if you stick mdadm between zfs and the disks - you'll have the write hole. The same layering violation concerns that apply to zfs also apply to btrfs as it also does volume management, raid, disk management, etc. If you run a scrub on btrfs or rebuild a disk it will only scrub/rebuild the blocks that are actually in use, etc.

I won't argue that btrfs on the whole is nowhere near as stable as zfs is currently, but most of the key features are very similar. They are both COW filesystems that are designed to run directly against disks, they both checksum all data to protect against on-disk modification and the write-hole, they both utilize their knowledge of what is on the disk to optimize how things like striping/parity are done, they both support very cheap snapshots, etc.

Anybody interested in storage at a low level would do well to have at least a general familiarity of both, regardless of preference.

http://comments.gmane.org/gman...
* journald will no longer forward all local data to another running syslog daemon. This change has been made because rsyslog (which appears to be the most commonly used syslog implementation these days) no longer makes use of this, and instead pulls the data out of the journal on its own. Since forwarding the messages to a non-existent syslog server is more expensive than we assumed we have now turned this off. If you run a syslog server that is not a recent rsyslog version, you have to turn this option on again (ForwardToSyslog= in journald.conf).

This is hardly news. The wpa_supplicant maintainer discovered that the 8th of april, only one day after heartbleed was disclosed.

Everyone wants his share of fame, I guess.

Linux and open source software in general has always been about survival of the fittest software, not by software being enforced by a company and by a bunch of people who haven't the faintest idea what they are doing. systemd is the total antithesis of the Unix philosophy - do one thing, do it well and have a bunch of focused interconnected system.

The people behind systemd are the same people who Linus Torvalds exposed as morons who kept breaking udev:

http://article.gmane.org/gmane...

Telling everyone to 'just get used to it' is not the way things are done.

Is "decommitting" something that [...] OpenBSD does (search this page [by David A. Wheeler about Heartbleed countermeasures] for "munmap") and everyone else lacks?

The second link has nothing to do with the topic

In the part of that page where "munmap" is mentioned, Wheeler is talking about properly using the C standard library's own memory allocator, which may return particular pages to the operating system. Perhaps I should have linked to the post by Theo de Raadt that Wheeler quoted: "If the memoory [sic] had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys." Also try man 2 munmap.

If some software that is released has problems, people should point it out. If a development process is flawed, people should point it out. If you work in open source software, specifically in security software, you should be prepared for people to criticize both your code and your development and testing safeguards. Maybe billrp could do better. Maybe (unlikely) I could do better. Maybe a hundred people on Slashdot could do better. But do we really want a hundred different open source SSL implementations all written by unknown people? That would not help the situation at all. Maybe all we need is one competing implementation by a different team with different methods, and maybe enough people saying "OpenSSL is not up to the job" might just inspire someone to build that team.

Free and open criticism is vital in security software. Nobody should ever be told to shut up about this kind of thing.

It does, but it is more likely just sloppy programming / testing. Don't forget the custom malloc implementation (via freelists) OpenSSL uses which contributed to the issue and Theo de Raadt eloquently ranted about.

http://article.gmane.org/gmane...

The bigger problem is coders that think they need to optimize for speed.
Read the horror here: http://article.gmane.org/gmane...

Ugh... premature optimization, the root of all evil. And now also the root of the biggest security hole ever.

Unless the mmap/malloc combo on the O/S you're using was able to purposely put guard pages after mmaped blocks so many malloced objects would end in such guard pages. Unfortunately...

Apparently OpenSSL uses its own allocator on top of the libc's (malloc). I.e. it only occasionally allocates a large chunk of memory from the C heap and then does its own allocations/reallocations in that (without anything like ASLR or guard pages of course). And apparently the particular sequence in which the OpenSSL library code allocates bits of memory using this allocator leads to a situation where the private key is always deterministically located behind the heartbeat packet space in memory. AFAICT this is why this bug is so remarkably portable and "works" reliably on all platforms.

http://article.gmane.org/gmane...

from the link,

> On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> > nobody gmail.com> writes:
> >
> >> "read overrun, so ASLR won't save you"
> >
> > What if malloc's "G" option were turned on? You know, assuming the
> > subset of the worlds' programs you use is good enough to run with that.
>
> No. OpenSSL has exploit mitigation countermeasures to make sure it's
> exploitable.

What Ted is saying may sound like a joke...

So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed. Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too. To a large extent these
come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc.

You can find the comment in their sources ...

#ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just

OH, because SOME platforms have slow performance, it means even if you
build protective technology into malloc() and free(), it will be
ineffective. On ALL PLATFORMS, because that option is the default,
and Ted's tests show you can't turn it off because they haven't tested
without it in ages.

So then a bug shows up which leaks the content of memory mishandled by
that layer. If the memoory had been properly returned via free, it
would likely have been handed to munmap, and triggered a daemon crash
instead of leaking your keys.

OpenSSL is not developed by a responsible team.

Apparently like this:

http://thread.gmane.org/gmane....

Having their own malloc() replacement that avoids the host OS "protections"

...had a lot of acerbic observations on the topic.

"I said this in 1971, in the very first week of PG, that by the end of my lifetime you would be able to carry every word in the Library of Congress in one hand - but they will pass a law against it. I realized they would never let us have that much access to so much information." http://samvak.tripod.com/busiw...

He was scathing on the topic of the attempts (which are largely succeeding) to convert us from an ownership society to a rentier society:

http://comments.gmane.org/gman...

"I worry that 100 years from now that 99% of foods will be GMO's [Genetically
Manipulated/Manufactured Organisms] and hence under copyright. . .and this
will enforce a copyright-powered hunger/starvation/malnutrition of the body
just as current copyright extensions are powering such for the mind.

The goal of WIPO is that EVERYTHING should HAVE to be paid for, plus a
royalty for the intellectual property. . .at a time when everyone COULD
have everything pretty much free of charge from replicator technology.

100 years ago the atom-powered Nautilus and atomic bomb were fiction,
only 50 years later the Nautilus was being built, and it sailed into
my own home town and their crew came to my school. . . .

Do you REALLY think it won't be even more different in the future?

But WIPO still wants to charge hugely for replicated food, just as
it does for replicated books."

The summary doesn't give a good idea of the scope of the project. The lead developer is targeting chips with low pincount. He considers more powerful smartphone class ARM's like found on the Raspberry Pi and Beaglebone Black to be too powerful for his project to make sense, and recommends running linux: http://comments.gmane.org/gman... That said, he offered to help if someone else wanted to do a port for some reason.

http://comments.gmane.org/gman...

I don't know that anybody was saying C was better than C++

Linus? He's a well known critic. I thought Gnomers embraced the philosophy, i.e. that real programmers didn't need any fancy OO abstractions...

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

Judge for yourself.

All I want to know is if we will be able to compile the kernel someday without the fucktardery of requiring a case sensitive filesystem for the netfilter source code. (So this is from the same guys who gave us that, huh?)

Was the old cert due to expire? I have thought before that it would be nice if my browser etc gave me a warning like "Certificate has changed but wasn't due to expire for another 3 months". This still gives the bad guys a window where a subverted certificate could be slipped in without notice, but it closes the window a bit.

Maybe. If I skip the web browser and run: msmtp --serverinfo --host=smtp.gmail.com --tls=on --port=587 --tls-certcheck=off

I get:
Activation time: Tue Sep 10 00:54:47 2013
Expiration time: Wed Sep 10 00:54:47 2014
SHA1: 10:75:E1:8C:DF:93:15:3B:A1:8F:CD:FE:D3:11:79:D5:16:43:77:BC

That's a pretty recent change. If there was overlapping time between the activation of this one and the expiry of the last one... problem is, I don't have a time machine and can't find out what the last one was, nor when it was set to expire.

Googling (look, just because they can MITM every site, I don't think even NSA is doing DPI on every HTTP transaction so they can pipe every web page through 'sed s/valid-signature/fake-signature/g' :) around for prior signatures reveals:

As of June 19, 2010: Activation time: Thu Apr 22 21:02:45 2010
Expiration time: Fri Apr 22 21:12:45 2011
SHA1: 1A:6F:48:8F:BE:5B:FD:92:D8:12:30:F9:22:CE:84:49:B3:43:BD:2C

As of August 16, 2011: Activation time: Wed Feb 16 12:38:09 2011
Expiration time: Thu Feb 16 12:48:09 2012
SHA1: DB:A0:2A:07:00:F9:E3:23:7D:07:E7:52:3C:95:9D:E6:7E:12:54:3F

As of October 2, 2012, another user reports a change from:
SHA1: F3:92:AE:B4:28:FE:64:03:6F:E1:55:ED:71:9E:5F:F6:88:90:5A:57
to:
SHA1: 34:B4:3E:66:71:D8:AC:5A:47:76:7F:B7:CD:E4:31:08:F4:A5:DD:A8
but didn't include the dates.

There was also a 2013 hit for what looked like a tls_fingerprint of 52:99:F2:7F:82:4F:79:5A:71:1F:FF:D3:BE:22:7C:88:06:62:89:76 also without dates.

So on the one hand, this may simply be an innocuous expiry of a cert for smtp.google.com that's related to this May 2013 note about upcoming changes. On the other hand, there's nothing else that says what the old fingerprint was, when it expired, nor what the new fingerprint ought to be. And on the gripping hand, maybe the root (if you'll pardon the pun) cause of the problem is that if the the user has no tls_trust_file defined, and if Google changed intermediate certificate authority... umm, dammit, now even I'm confused. I think I sympathize with OP, though. There needs to be an easy-to-google, bing, apt-get, or git-init means by which of seeing the history of what's legit at any moment in time. It's up to the user to decide how many ISPs to run the search query from, or even to pick up the phone and call a friend in a non-US country and ask them to do the search and see if they get the same results.

Your problem seems to be that you believe every person involved to be a land-mine who will send you sky-high the moment you put your foot wrong. That's completely wrong, even if I suppose Linus has a pretty short fuse since he does have a lot to do, and really no time to deal with derps, fools and incompetents. Anyway, you have to keep in mind that the explosions you regularly see reported usually are preceded by some sort of long-standing conflict or shenanigans.

Honest mistakes or errors are a lot more tolerable than people who do stuff they damned well should know better than trying, or just dig in when they are told they are wrong. Just look at the mail Linus sent wrt Kay Sivers and udev. That's pretty abrasive, but don't tell me it came out of the blue.

I had this experience too. I managed to get it running with a single X session, but XRandR only supports one "screen" (in X11 terms) per GPU, which means that you can drag windows between monitors on the same GPU, but the monitors on the other GPU are separate and you can't drag windows over to them. (Here's a corroborating mailing list post.) Window dragging works with Xinerama (windows maximized properly etc), but Xinerama doesn't work with 2D hardware acceleration, so you lose that.

Even with Xinerama, I still found some oddities. Menus in some programs (I guess probably "in some toolkits") would open aligned with the top of my smallest monitor -- if I maximized a program on my main monitor and tried to open the menu for it, the menu would show up a couple of inches away from the menu bar. XFCE's system menu on smaller monitors would try to open aligned with the top of the biggest monitor. The mouse behavior in the corners of monitors was terrible (either the mouse went into the dead zone, or it jumped several inches to fit onto the smaller monitor, depending on whether I was using Xinerama or XRandR), making it really difficult to hit anything in a corner.

None of this stuff happens on Windows. It just works. I don't have to give up 2D acceleration. And that's with XP, which is almost a decade older than the Linux version I was testing with. I was expecting the same from Linux, but... nope.

On the plus side, while writing this post I discovered that XRandR 1.4 is a thing now, and apparently it does include support for multiple GPUs. Maybe this stuff will actually work now.

There have been other problems, too (off the top of my head), like

• Then there's stuff like some guys arbitrarily deciding to reimplement the system installer and on top of that, to remove the old one in the time window between 9.0 RC 3 and 9.0-RELEASE, see (along with some elitist Linux bashing going on:) here and here

Arbitrary? Retiring sysinstall has been discussed for about 15 years. After complaints from everybody that tried to maintain it (including me - I did a couple of fixes, including the "restart" dialog box and ISTR some parameter checking) I was talking to the Lizard guys at Qt about replacing sysinstall back in 1999, and at that point the complains were by no means new. There has been an ongoing wish to retire it (with the codebase considered more or less unmaintainable by everybody) since, with no substantial architectural fixes/refactoring happening because the environment for developing and testing the installer sucks.

I seem to also remember a couple of attempts at rewriting it in the meantime (including hiring somebody to write a replacement), with this one being the only one that actually managed to pull through. Though I've not been involved for a while, I can say that when I last participated in the discussion, the project was ready to lose features in the short term in order to get a reasonable installer in place. From the discussion that you're referring, that seems to have happened. It is by no means arbitrary, though losing features of course is annoying.

There have been other problems, too (off the top of my head), like

• Then there's stuff like some guys arbitrarily deciding to reimplement the system installer and on top of that, to remove the old one in the time window between 9.0 RC 3 and 9.0-RELEASE, see (along with some elitist Linux bashing going on:) here and here

Arbitrary? Retiring sysinstall has been discussed for about 15 years. After complaints from everybody that tried to maintain it (including me - I did a couple of fixes, including the "restart" dialog box and ISTR some parameter checking) I was talking to the Lizard guys at Qt about replacing sysinstall back in 1999, and at that point the complains were by no means new. There has been an ongoing wish to retire it (with the codebase considered more or less unmaintainable by everybody) since, with no substantial architectural fixes/refactoring happening because the environment for developing and testing the installer sucks.

I seem to also remember a couple of attempts at rewriting it in the meantime (including hiring somebody to write a replacement), with this one being the only one that actually managed to pull through. Though I've not been involved for a while, I can say that when I last participated in the discussion, the project was ready to lose features in the short term in order to get a reasonable installer in place. From the discussion that you're referring, that seems to have happened. It is by no means arbitrary, though losing features of course is annoying.

I recall frequent kernel panics while booting that were related to the Intel Ethernet chipset on a SuperMicro H8SGL-F board (not exactly the least common hardware) in a released version (I think it was 8.2 or 8.3), which was probably this. Rather annoying.

There have been other problems, too (off the top of my head), like

• the mediocre PAE support,
• and the in my eyes rather ungracefully handled transition to Xorg 7.2 in the 6.x releases, which for me didn't work at all like the documentation said, although this was not a problem of the base system, but the ports collection.
• Then there's stuff like some guys arbitrarily deciding to reimplement the system installer and on top of that, to remove the old one in the time window between 9.0 RC 3 and 9.0-RELEASE, see (along with some elitist Linux bashing going on:) here and here
• or the transition to Clang at a time when it wasn't even ready for the non-x86 architectures!

So sometimes I ask myself whether this OS is really ready for prime time

But enough of the rant. I've been sticking to it since 2000 and for most of the time it just runs and does its job. It's got some nice coherent documentation too.

I recall frequent kernel panics while booting that were related to the Intel Ethernet chipset on a SuperMicro H8SGL-F board (not exactly the least common hardware) in a released version (I think it was 8.2 or 8.3), which was probably this. Rather annoying.

There have been other problems, too (off the top of my head), like

• the mediocre PAE support,
• and the in my eyes rather ungracefully handled transition to Xorg 7.2 in the 6.x releases, which for me didn't work at all like the documentation said, although this was not a problem of the base system, but the ports collection.
• Then there's stuff like some guys arbitrarily deciding to reimplement the system installer and on top of that, to remove the old one in the time window between 9.0 RC 3 and 9.0-RELEASE, see (along with some elitist Linux bashing going on:) here and here
• or the transition to Clang at a time when it wasn't even ready for the non-x86 architectures!

So sometimes I ask myself whether this OS is really ready for prime time

But enough of the rant. I've been sticking to it since 2000 and for most of the time it just runs and does its job. It's got some nice coherent documentation too.

I have yet to hear a single complaint that their system is too slow, not one.

The AMD V105 in my Acer Aspire One is too slow. I've used older generation Atom CPUs that were faster.

So unless a person is in one of those rare fields where they need every possible cycle they can squeeze out of a machine they really are just pissing money away.

I usually don't buy AMD to avoid the repeated erratum issues.

But that still don't explain why in the fuck Intel don't get busted,

They did.

Bitcoin exchanges are a target right now at the current exchange rates, but I was thinking just a little while back, isn't it strange that somebody who released the original protocol is unknown and wishes to stay anonymous? I thought about that for a little bit, there are a number of possibilities. Of-course somebody who had the original idea could run the hash generation for a much longer time before anybody started doing it as part of a mining (proof of work) network. I don't know, it's hidden in plain sight

This feature is then used in the Bitcoin network to secure various aspects. An attacker that wants to introduce malicious payload data into the network, will need to do the required proof of work before it will be accepted. And as long as honest miners have more computing power, they can always outpace an attacker.

- good, what if somebody had a much longer stretch of time to work out the answers before they could even become questions? It's not like those transactions are random.

What other motives can somebody have to release a protocol like this one potentially to be used by millions of people who see this as a way to make money? Giving people incentives to come up with faster SHA generators? Somebody who wants to break encryption mechanisms by generating huge amounts of SHA codes against various data?

I think without actually getting into the source code it's impossible to read the answers to any of these questions, so maybe that's the next step, read the source code.

1. Make sure clone propagates errors from checkout to the final exit code.
2. Teach clone to run check_everything_connected.

"

Given that Linux is running by Linus, you can bet that will never happen. Just look at how he utterly rejects the idea of using even C++, even for userspace tools: http://article.gmane.org/gmane.comp.version-control.git/57918

Cuz, he said a mouthful today...
Re: Reaching out to Amazon for credit?

It's about Ubuntu. It's about Ubuntu's malicious functionality,
spyware. This is egregious behavior, and it calls for the strongest
response. If it is accepted as normal, others are likely to follow
the same path! We must respond to this as to a shocking crime.

Does Ubuntu have "positive aspect"? Does it have variants that don't
include the spyware? They don't change the conclusion. Positive
aspects can't excuse this crime. If Ubuntu is guilty only in some
variants, that's still guilty.

We must punish Ubuntu so hard that anyone else will think twice before
following the same route -- and so that Ubuntu will either pull back
or be totally discredited.

Shorter Stallman: Kill Ubuntu!

In a scathing rant posted to a GNU project mailing list

Where is this scathing rant? All I can find is a extremely polite, well written airing of grievance and resignation.