Slashdot Mirror

I seem to remember the last Lenovo laptop I used had a UEFI firmware bug http://xen.markmail.org/messag... that made setting up zen more of a pita than it needed to be.

Linux 3.11... So, it's actually happening. I thought it was sarcastic, but now I see the prophesy was self fulfilling.

In other words, we'd have an increasing level of instability with an odd release number, depending on how long-term the instability is.

- 2.6.<even>: even at all levels, aim for having had minimally intrusive patches leading up to it (timeframe: a week or two)

with the odd numbers going like:
- 2.6.<odd&gt: still a stable kernel, but accept bigger changes leading up to it (timeframe: a month or two).
- 2.<odd&gt.x: aim for big changes that may destabilize the kernel for several releases (timeframe: a year or two)
- <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote the kernel to be a microkernel using a special message-passing version of Visual Basic. (timeframe: "we expect that he will be released from the mental institution in a decade or two").

- Linus

I would be interested to have a reference to this law.

Google the magic phrase "it shall be no defence", there's a pile of laws on the books of various countries that explicitly exclude non-knowledge that something you've been charged with was wrong (and specifically that no matter how much care you take to not break the law, if you're later charged you can't claim that you did everything possible to make sure what you were doing was legal as a defence). Gah, convoluted wording there, it's late...

The phrases "it shall be no defense" and "it shall be a defence" are actually quite common in laws. They are intended to clearly define the acts or ommissions which constitute the crime. Most of the Google hits for "it shall be no defense" are in laws defining indecent assault on a child. They state that the consent of the child is "no defense". The presense of this phrase does not by itself make a law unreasonable.

You seem to be refering to this passage from New Zealand's law which as quoted at http://markmail.org/message/ughwxerisy5kgwh4 says:

(3) It shall be no defence to a charge under subsection (1) of this section
that the defendant had no knowledge or no reasonable cause to believe that
the publication to which the charge relates was objectionable.

This paragraph creates a responsibility to aquaint oneself with the law and remove from one's library any publications that are "objectionable". This may or may not be reasonable, but it is still talking about a situation in which the accused knows that the publication exists and is in his possession. So the claim (on the same page) that it makes a person guilty of possession even if he does not know that a publication of any kind is lying on his lawn seems fanciful, even if it is attributed to a lawyer.

This is a matter of properly parsing the text of the law. The "no knowledge or reasonable cause to believe" refers to knowledge of the fact that the publication is considered objectionable, not of the fact that it is in the accussed's possession (let alone lying abandoned on his property).

Indeed. You will usually (for example) find my replies to messages on mailing lists either inline or at the bottom (unless I am replying from iOS, which can make it difficult to post anywhere but the top).

MarkMail archives a bunch of OSS mailing lists with a nice web interface to the archives. Senders to the list still need to use SMTP though. http://markmail.org/

If your list is private, it appears MarkMail may still work, but you'll need to contact them for pricing. I'm sure other comments will contain better options for private email list management via web interface.

The one nice thing about regular old email is the low tech knowledge required to contribute to the discussion. From the summary, it appears all the current members know how to email already (though I'm sure top-posting is a problem).

Gad, I hate MIME.
Larry Wall, 13 Sep 1995

Ruby is Smalltalk meets Perl, really, it's not much like Haskell. You can do some functional things in it, but many nice features of functional languages like Haskell are not present. Currying, ZF-expressions, argument pattern matching, ...

I was struck by Matz's comments on Ruby when reading up on why list comprehensions never made it in.

It's too functional so that I'm afraid it would not work well with OO nature of Ruby. Maybe it's matter of notation.

http://markmail.org/message/agv5qlyrh2hhncuw (I can't find the original source, annoyingly)

I'm a bit confused to why Google has taken down all the emulators since they are used for legal purposes (see homebrew).

I asked about this on Fedora's legal mailing list once, and let me paraphrase the answer I got: The Betamax defense to contributory infringement of copyright requires a substantial non-infringing use. Two dozen homebrew games compared to a thousand infringing ROMs is not clearly substantial to the point where Red Hat would have an open-and-shut defense against Nintendo.

I got this link from my twitter feed, based on the assumption that Dart is Dash renamed.

http://markmail.org/message/uro3jtoitlmq6x7t

So there's hope.

As for why one wouldn't be estatic over javascript, there are many good reasons in that email, many others in The Good Parts book.

There's always room for something better, while not denegrating the existing.

ZFS is buggy and unreliable:

http://www.mouldy.org/zfs-the-final-straw
http://opensolaris.org/jive/thread.jspa?messageID=473421&tstart=0
http://mail.opensolaris.org/pipermail/zfs-discuss/2008-January/016042.html
http://forums.freebsd.org/showthread.php?t=7682
http://markmail.org/message/4prch5ydto6nxquf

I'm interested in Tux3 and (particularly) Hammer though.

http://www.ntecs.de/blog/articles/2008/01/17/zfs-vs-hammerfs/

I didn't know. Do you happen to know about it's video output at 1920x1080? I heard that memory limitations might be a problem. http://markmail.org/message/ixj3lf2ebvlufs2y

I don't need it to play video, just have an X11 display that doesn't look flickery on a 24" LCD.

Maybe that's a more sensible proposal.

But what's not so sensible is it's taken about 7 years since I tried to get people to do something about it:

http://markmail.org/message/pgcka6wlxgbfyep7
http://www.mail-archive.com/mozilla-security@mozilla.org/msg01448.html

That's a pretty long time. Oh well, maybe we'll see a brake pedal eventually. Like I said, I don't care how it looks as long as it works and is easy to use.

Heh at least I'm not a patent troll. In my experience ideas are easy - getting stuff implemented is the hard part. I'm happy if people just improved stuff faster.

p.s. Maybe it'll be another 7 years before someone actually implements something like this: https://bugs.launchpad.net/ubuntu/+bug/156693
Too bad after all the years and alleged billions all we got was UAC from Microsoft, and maybe a few sandboxed browsers.

Feel free to correct the Wiki article. While you're at it, you might want to get the myriad web sites which disagree with you to fix their pages.

Two copies of every file are managed by a SVN checkout - the base file and the working file. If the filesystem could store these together then the cost would be halved I understand that btrfs will support a copy-on-write version of cp, which should allow this.

"Konqueror -> Settings -> Configure Konqueror -> Crypto -> SSL Signers -> Import."

Maybe this is fixed in the nightly builds or in 4.2? I am using 4.1.3 right now, and yes, that option *exists* but it does not work, it does not propagate the public keys globally, and it does not retain those settings after hitting "OK." Claiming that is the solution to my problem is kind of like calling your alpha release "version 4.0 stable." Hmm...

"the "OLE framework" in KDE is called KParts, and the infrastructure hasn't changed one bit between KDE3 and KDE4."

Except that the use of KParts has changed. In KDE3, all the KParts components played well with each other (except for the Kontact KParts, which only embedded in Kontact), which is exactly what OLE is supposed to do. In KDE4, a few components still embed in one another, but nothing on the level of KDE 3. The OP was claiming that KDE 4.1 was approaching 3.5 in terms of functionality; where are the useful, play-nice-with-others KParts?

"it doesn't embed into Dolphin, no, because that's not Dolphin's design goal. i don't have 4.1 nearby to test this on, but in 4.2 you can navigate directly into tarballs seamlessly in Konqueror."

Then Dolphin was poorly designed. I do not need a file manager if all it does is browse normal, already mounted file systems. Dolphin certain supports some level of OLE, the fact that it cannot embed an ArK component is, once again, an oversight, and an embarrassing one. Maybe this will be fixed in 4.2.x? 4.3?

"currently Ark relies on KParts for previewing files without extracting. an "open with" that would extract to a temporary location and launch the app would be nice, though."

And once again, they do not play well with others. Why not have an Okular component embed into ArK? Why force me to extract a PDF file just to view it? If the file manager does not embed an ArK component, and ArK cannot embed an Okular component, then why would I use Dolphin/ArK when I could just use a terminal? In 3.5, there was no question: KPDF embedded in ArK, ArK embedded in Konqueror, and the software stack was more useful than trying to navigate using just a terminal.

"which shortcuts would those be? actually, better yet, go to bugs.kde.org and report it there so it can be handled."

http://bugs.kde.org/show_bug.cgi?id=165441#c2

Notice that they did not even PLAN to fix it in 4.1. Maybe it will be fixed in 4.2? I can only hope so, because it is clumsy, annoying, and frankly stupid for shortcuts to fail. What is very odd, though, is the kxkb shortcuts work in Fluxbox; oh wait, that is confirmed too:

http://markmail.org/message/dxz6fntbrp73cljl

Again, NO PLANS to fix. Why are there no plans to fix this? Keyboard shortcuts are the only way to keep a large GUI like KDE from being too clumsy to use, but they are sitting around scratching their heads and not even trying to get this working. Again, one is forced to ask just what design methodology they are adhering to, if any. Another commenter noted that there are other shortcut daemons; is that really what we are stuck with?

Based on this post, it looks like "AddTrust External CA Root" is the one in question.

To disable it in Safari (and anything else that uses the Mac OS X keychain, such as Mail.app), open the Keychain Access program, which should be found in the Utilities folder in you Applications folder. In the keychains box in the upper left, click on System Roots. Double-click on the AddTrust External CA Root certificate, click the triangle next to Trust to expand that section, and in the popup menu next to "When using this certificate", change it to Never Trust. Close the window, and if you're prompted for your Administrator password, enter it. You should see the little certificate graphic in the left column of the list next to the name get a red X on top of it, and the status near the top should change from "This certificate is valid" to "This certificate is marked as not trusted for all users".

This subject is being discussed by Firefox developers, Comodo CA people, the person who reported the problem, and somebody named "Patricia" from CertStar, the issuer, here.

Robert Alden of Comodo says they "have suspended Certstar's reseller activities until our investigation has been completed." The CertStar site now says "Due to technical issues we are unable to process orders at this time. We are working hard to resolve the issue and apologize for any convenience caused. Please check back later."

The Mozilla team is discussing revoking some root CA keys.

This subject is being discussed by Firefox developers, Comodo CA people, the person who reported the problem, and somebody named "Patricia" from CertStar, the issuer, here.

Robert Alden of Comodo says they "have suspended Certstar's reseller activities until our investigation has been completed." The CertStar site now says "Due to technical issues we are unable to process orders at this time. We are working hard to resolve the issue and apologize for any convenience caused. Please check back later."

The Mozilla team is discussing revoking some root CA keys.

Looking at this cert further, it's a very wierd certificate. "Issuer" of ""www.mozilla.com" has "O=Comodo CA Limited". That's descended from "Positive SSL CA", for which "Issuer" has "O = The USERTRUST Network". That's descended from "UTN-USERFirst-Hardware", for which Issuer has "O = AddTrust AB". That's descended from "AddTrust External CA Root". Why is a Comodo cert being issued under AddTrust? Comodo is a root CA itself, with its own root certs in major browsers. Something is not right here.

So who's AddTrust? Their web site says "Under Reconstruction". This does not look good. Checking the Internet Archive, we find "JOIN THE ADDTRUST FAMILY Gain an edge over your competitors by providing co-branded PKI services"

AddTrust went beyond using resellers. They apparently allowed subordinate CAs to issue certs in AddTrust's name: AddTrust's rapid Trust Service Provider (Licensee) start-up package allows you to deliver cutting-edge public key infrastructure (PKI) services cost-effectively and in a way that best complements your business model. Literally within months you can start selling pre-packaged outsourced PKI services allowing your customers ... AddTrust's globally recognized PKI brand is designed for co-branding with companies recognized for high-quality IT services and products. ... Rather than relying on external certification authorities, you can easily provide high-end certificates yourself by becoming an AddTrust-licensed Trust Service Provider. This allows you to decide how much of the underlying secure infrastructure you want to run and invest in yourself.

The relationship between Comodo and AddTrust is mentioned in this email. Robin Aldin of Comodo wrote: There is no ongoing relationship with AddTrust AB, Sweden. I'm not even sure if AddTrust AB still exists as a company. I think AddTrust may exist now only as a brand of ScandTrust AB. Sweden - although Comodo does have the right to continue using the root CA certificates which we purchased from them and which bear the AddTrust name.

So the party ultimately responsible for this certificate is out of business?

This idea has been around since 2005 at least...

For more details on why things are what they are in new Ruby, and what can go wrong, read this thread. For those who might be unfamiliar with the names - Yukihiro "Matz" Matsumoto is the Ruby mastermind, and another well-known person there is Tim Bray, these days mostly known as the editor of W3C XML spec, and the author of the very first XML parser.

It isn't Usenet - rather mailing lists. But there's quite a bit of crossover. http://markmail.org/

Some people suggested removing the animation, which was a problem because it interfered with maximized windows, and he said no.

The "cashew" would cover up a window whether it's animated or not. :P

Some people suggested allowing people to move or relocate the cashew because it interfered with panels at the top, and he said no.

Not according to this email. Looks to me is that Aaron disagrees with the various methods of removing the cashew that have been proposed so far, and that ways to do so that don't suck haven't been proposed in time for KDE 4.1.

Some people suggested having the cashew disappear when the panel is locked, and he said no.

The panel cashew does disappear when the panel is locked but locking the widgets onto the desktop doesn't get rid of other activities. The way I would think to do that is to have the cashew disappear automatically if the one and only activity has its widgets locked but I don't care enough (I mean seriously, a cashew?) to submit a patch.

The worst thing is he repeatedly said everyone was too stupid to understand his design, which he had no intention of explaining. He said users can't comment on design or UI issues. That is a problem.

In all fairness I think this happened after like the third time he tried to explain the same thing and got the same comments back. You can only answer the same question to X number of different people before you too turn into an asshole. ;)

And besides (this came up later I think) I'm pretty sure the exact perjorative term used was not "stupid" but the email thread gives me emotional baggage so I'm not going to dig it up to double-check.

Anyways KDE appreciates and needs user feedback but what we don't need are personal attacks on our developers from users, which is what led to Aaron-hates-assholes-ivus. Really KDE the project kind of let Aaron down on this because he eventually came to receive quite virulent attacks even about software he doesn't write or maintain just because he's the highest profile KDE developer and no one stepped in to get it from getting out of hand.