Slashdot Mirror

html5 can replace flash, check this link on how firefox can replace flash

still not perfect, but getting better. it will replace flash, just like PDF.js can replace PDF plugins in browsers

pdf.js is okay for simple .doc files translated to PDFs, but for more complex documents, it has a LONG way to go. I have to open about 50% of PDFs in an external viewer since PDF.js renders them badly.

html5 can replace flash, check this link on how firefox can replace flash

still not perfect, but getting better. it will replace flash, just like PDF.js can replace PDF plugins in browsers

The "writeup on NFTables" linked in the submission is very outdated. LWN's article from two months ago is a lot more useful. See also this this brief news item (“not ready to replace iptables yet”) and the nftables web page.

The "writeup on NFTables" linked in the submission is very outdated. LWN's article from two months ago is a lot more useful. See also this this brief news item (“not ready to replace iptables yet”) and the nftables web page.

Actually, iptables is sub-optimal, that's the problem: http://lwn.net/Articles/531752/

if it s a question about Linux, check LWN. They already have the question and the answer. https://lwn.net/Articles/325194/

Entropy Broker: A project to allow one computer to act as a randomness server to others. Could use any actual hardware machine to seed any number of VMs.

See also the comments in the LWN article, where someone with the user name "starlight" simply sends random data over SSH and then the receiving computer uses rngd to mix that data into the entropy pool. Simple, and simple is good.

https://lwn.net/Articles/546428/

http://www.vanheusden.com/entropybroker/

I would argue that the Windows TCP/IP stack is the bit that processes the packets in the kernel and this was originally licensed from Spider and then rewritten for Windows 3.5 NT and neither was BSD derived. The current Windows networking bits that are BSD derived are userland legacy utilities like ftp, nslookup and telnet and aren't necessary to have a useful TCP/IP stack.

This myth needs to be allowed to rest - BSD has plenty of real wins that are more recent.

As long as MariaDB is requiring copyright assignment, there's every reason to believe it will be sold off again the same way MySQL was. The FSF gets away with that for GNU projects because they've never abused contributor trust before. Monty is no FSF, and there's no reason believe MariaDB will remain outside of commercial control any better than MySQL did. I can't believe people are falling for the same trick again.

PostgreSQL aims for SQL standards conformance as much as possible. It's hard sometimes due to the difficulty of participating in the standard process. The idea that MySQL does a better job in that area is kind of odd though. You'll have to list some sample Postgres "oddities" to be credible with that claim.

Three items that may be of interest:

* A short history of btrfs [LWN.net] (2009) (highlights)
* How ZFS continues to be better than btrfs — Rudd-O.com in English (2012) (highlights)
* Btrfs & ZFS, the good, the bad, and some differences. | www | grep storage (2013)

Forget SELinux, use http://grsecurity.net/.
See e.g. https://lwn.net/Articles/538221/

There was an attempt to backdoor the kernel a few years back. I don't believe the perpetrators were ever revealed.

You still have to trust them to find things like that, unless you are able to verify all their changes yourself.

There was an attempt to backdoor the kernel a few years back. I don't believe the perpetrators were ever revealed.

Available at https://github.com/SilentCircle, but now we have the problem of validating the binaries are built from the code. This is subtle: see, for example, https://lwn.net/Articles/565113/

Actually, all they need is the CA to sign a cert with the "allowed to sign" bit set. Then they can MITM anyone. Given TrustWave sold one of these to a company not so long ago, I doubt it would be hard to find a CA willing to pony up. Given some CA's in the world are government owned organisations, this has almost certainly happened somewhere already.

As others have said, what keeps the current PKI system working isn't the inherent trustworthiness CA's (they aren't trustworthy), or because NSA has scruples (it doesn't). Its the fact that in time they will almost be certainly found out.

Where I live at least, in Australia, I am not sure what proportion of SSL connections are already MITM'ed. But it would have to be above 10%. All schools do it, many government offices do it, many businesses do it.

The thing all these organisations have in common is they own the computers they are compromising. The corollary is if you care about your privacy, you need to use only hardware you control. But this has been known for years. What this story makes plain is you must also use software "you control", otherwise NSA and others will backdoor it just as eagerly as they have done with the hardware. You can't absolutely control all software you use of course, but open source is a good proxy.

Ubuntu stopped giving money to Kubuntu, but Kubuntu is alive and well.

http://lwn.net/Articles/491498/rss

For those unwilling to click through:

Kubuntu to be sponsored by Blue Systems
[Distributions] Posted Apr 10, 2012 17:33 UTC (Tue) by corbet

The Kubuntu project recently lost its sponsorship from Canonical, which is pursuing its fortunes in other areas. The project has now announced that it will be sponsored by Blue Systems instead. "Blue Systems sponsors a number of KDE projects and will encourage Kubuntu to follow the same successful formula as it has always had - community led, KDE focused, Ubuntu flavour." The actual extent of this sponsorship is not clear at this time.

--
BMO

I'll eat my hat(*) if bog standard Linux or FreeBSD installations try to execute anything on a USB stick unless it's rebooted with that stick as boot medium

They won't do that intentionally. But bog standard Linux machines can certainly be infected just by inserting a compromised USB stick.

First of all, the stick will be mounted. Typically, this happens automatically, but if not, the user will still have to do it manually. The USB filesystem can be modified to contain just the right corrupt data structures to trigger a kernel bug, leading to a compromise of the machine. If you think this is far out, think again. This was 2006, but don't worry, the NSA has zero-days on file if they need them. It is well-known that kernel "oopses" (such as this bug in ext4 from 2013) can often be converted into full exploits by a sufficiently determined adversary.

Assuming your Linux distro has a graphical desktop, you may next try opening the stick in a file browser, such as Nautilus. (Or it may even autolaunch when you insert the stick.) This too can cause your computer to be compromised, if e.g. the stick contains a PDF, which has been modified to contain just the right corrupt data structures to trigger a userspace bug in the program that generates the PDF thumbnail. By the time you think, "Wait, I never put any PDF on this stick", you're already compromised. If you think this is far out, think again. This was 2011.

If you're really paranoid, you'll forgo filesystems and desktop environments entirely and just dd plain ASCII files directly to the USB block device. But if your networked computer has been infected, you can never be sure that it's only doing that...

I'll eat my hat(*) if bog standard Linux or FreeBSD installations try to execute anything on a USB stick unless it's rebooted with that stick as boot medium

They won't do that intentionally. But bog standard Linux machines can certainly be infected just by inserting a compromised USB stick.

First of all, the stick will be mounted. Typically, this happens automatically, but if not, the user will still have to do it manually. The USB filesystem can be modified to contain just the right corrupt data structures to trigger a kernel bug, leading to a compromise of the machine. If you think this is far out, think again. This was 2006, but don't worry, the NSA has zero-days on file if they need them. It is well-known that kernel "oopses" (such as this bug in ext4 from 2013) can often be converted into full exploits by a sufficiently determined adversary.

Assuming your Linux distro has a graphical desktop, you may next try opening the stick in a file browser, such as Nautilus. (Or it may even autolaunch when you insert the stick.) This too can cause your computer to be compromised, if e.g. the stick contains a PDF, which has been modified to contain just the right corrupt data structures to trigger a userspace bug in the program that generates the PDF thumbnail. By the time you think, "Wait, I never put any PDF on this stick", you're already compromised. If you think this is far out, think again. This was 2011.

If you're really paranoid, you'll forgo filesystems and desktop environments entirely and just dd plain ASCII files directly to the USB block device. But if your networked computer has been infected, you can never be sure that it's only doing that...

I'll eat my hat(*) if bog standard Linux or FreeBSD installations try to execute anything on a USB stick unless it's rebooted with that stick as boot medium

They won't do that intentionally. But bog standard Linux machines can certainly be infected just by inserting a compromised USB stick.

First of all, the stick will be mounted. Typically, this happens automatically, but if not, the user will still have to do it manually. The USB filesystem can be modified to contain just the right corrupt data structures to trigger a kernel bug, leading to a compromise of the machine. If you think this is far out, think again. This was 2006, but don't worry, the NSA has zero-days on file if they need them. It is well-known that kernel "oopses" (such as this bug in ext4 from 2013) can often be converted into full exploits by a sufficiently determined adversary.

Assuming your Linux distro has a graphical desktop, you may next try opening the stick in a file browser, such as Nautilus. (Or it may even autolaunch when you insert the stick.) This too can cause your computer to be compromised, if e.g. the stick contains a PDF, which has been modified to contain just the right corrupt data structures to trigger a userspace bug in the program that generates the PDF thumbnail. By the time you think, "Wait, I never put any PDF on this stick", you're already compromised. If you think this is far out, think again. This was 2011.

If you're really paranoid, you'll forgo filesystems and desktop environments entirely and just dd plain ASCII files directly to the USB block device. But if your networked computer has been infected, you can never be sure that it's only doing that...

Since at least 2010.

I work in kernel security and I would say we have improved. You can't just tell people "don't make mistakes" and expect security to improve the only way you can improve is by improving the process.

1) We've added a few exploit prevention techniques like hiding kernel pointers.
2) Our fuzz testers have improved.
3) Our static checkers have improved.

But we're not perfect.

For example, we earlier this year we merged user namespaces. Obviously this is tricky code which deals with security. People had been working on it since 2007, but even after five years we all knew there were going to be some security bugs which we had missed. Code has bugs. That's life. But user namespace is a valuable feature and we had done everything we knew how to do.

Actually, in some ways, user namespaces will improve security overall because we can use it to remove a setuid binary from the Chrome browser.

Btw, you can't just look at CVE count. If could be that the bug is old but it was only found recently because of the improved tools. Also two years ago we probably wouldn't have issued a CVE for info leaks like CVE-2013-2148.

http://lwn.net/Articles/563204/

There's an interesting article over at LWN about /dev/random and /dev/urandom

http://lwn.net/Articles/489734/

Electronic voting is not secure and can never be made secure.

I won't rehash all my arguments here; if you're interested read the "dskoll" comments on this LWN article.

I remember reading that that the GNU GPL is a license, not a contract, and that most proprietary software is accompanied by both. My vague understanding is that lawyers aren't familiar enough working with the GNU GPL's 'bare license' situation.

http://forums.linuxmint.com/viewtopic.php?f=47&t=99890

http://fixunix.com/redhat/489285-rhel-5-1-rhel-5-2-dependency-hell.html

http://www.freelists.org/post/oracle-l/Linux-X86-26-Oracle-9204-and-RPM-Dependency-Hell

http://unix.stackexchange.com/questions/53077/firefox-circular-dependency-hell-on-linux-mint-13

http://linuxgazette.net/issue71/tag/3.html

http://lwn.net/Articles/198455/

http://forums.opensuse.org/english/get-technical-help-here/applications/406017-does-dependency-hell-still-exist-2.html
* "The best (worst) way to get dependency hell is to add too many repositories. Eventually one will find the right combination of conflicting repositories to create a situation of dependency hell."
* "The problem is the more repositories that are added, the less and less likely that applications are built against the same set. "
* "Dependency hell ALWAYS exists. ALWAYS (Yes, Debian users, I'm talking to YOU). The question is whether or not if somebody tries to NOT go to dependency hell, is the system going to take them there anyway."

http://unix.stackexchange.com/questions/32594/fedora-16-dependency-hell

http://www.eonlinegratis.com/2013/dependency-hell-trying-to-install-gcc-on-centos4/

Oh, dependency hell is real alright!

My point was entirely relevant and you're just trying to weasel out of it with a false dilemma. Then you attempt to sweep inconvenient facts under the rug as "irrelevant," and you have the bombast to attempt to portray your willingness to do so as generosity. Such an argument is worthy of Schopenhauer's Art of Being Right; for you to argue in such a fashion and then perpetually loudly claim that everything anybody else says is fallacious is pretty laughable.

You were saying there are tons of LO contributions being dual-licensed for AOO inclusion because all those who "don't care about the license bullshit" are "happy to work with both projects." I countered that the dual-license contributors are not that numerous, and that an absence of philosophical objections to the Apache license does not entail a willingness to license LO related work for use by AOO-- in particular, some people have become unwilling to do so because of the caustic, acerbic, and rude behavior that has been exhibited on the AOO dev list and elsewhere.

Any search for your posts here, at lwn, or on the Apache mailing lists will turn up this kind of stuff. From the security list debacle two years ago to the present, just about any time you've opened your mouth you've alienated people, including many who might otherwise have contributed in some way to AOO's success. I haven't been following aoo-dev for a while, and I'm not on top enough of all the drama you generate to give an itemized list here, but it doesn't take much looking to find you behaving like an adolescent and people being disgusted by it.

In any case, I too am done talking with you. Maybe once you've driven AOO into the dirt with your toxic "leadership" and been let go by IBM you'll rethink your ways of dealing with people.

zram (previously called compcache) has been around for a bit longer. This LWN article compares the three different memory/swap compression options in the kernel, each of which has its own pros and cons.

Take a look at Twibright Optar: http://ronja.twibright.com/optar/ (A review is at: http://lwn.net/Articles/242735/)

First, it wasn't claimed that the NSA that wanted the backdoor, it was the FBI. Second, Theo de Raadt said that the company, NETSEC, accused of being hired by the FBI to put the backdoor in the IPSEC code "was probably contracted to write backdoors as alleged.". However, after performing an audit he came to the conclusion that the backdoor never made it into the mainline tree. He wasn't 100% sure, though, and just because this particular attempt failed doesn't mean the FBI gave up trying to get backdoors into OpenBSD, or any OSS project.

That's not quite what Theo said..
https://lwn.net/Articles/420858/ ...
  (g) I believe that NETSEC was probably contracted to write backdoors
                as alleged.
        (h) If those were written, I don't believe they made it into our
                tree. They might have been deployed as their own product.
        (i) If such NETSEC projects exists, I don't know if Jason, Angelos or
                others knew or participated in such NETSEC projects.
        (j) If Jason and Angelos knew NETSEC was in that business, I wish
                they had told me. The project and I might have adjusted ourself
                to the situation in some way; don't know exactly how. With this
                view, I do not find Jason's mail to be fully transparent.

BTW, the guy making the claim is named Gregory Perry. Here's a synopsis he wrote to Cryptome.org about the OpenBSD issue and the FBI's need to weaken crypto standards for the purpose of domestic surveillance.
  http://cryptome.org/2012/01/0032.htm

Obviously there is a lot more to this story than a one page synopsis, but I think what is important to make mention of is the close nexus between supposedly unfriendly governments such as Iran and the US. In 1995 the FBI was adamantly against any relaxation of encryption export regulations, yet they did an abrupt about-face on the issue in 1999 (for example,

http://www.nytimes.com/1999/10/11/business/technology-easing-on-software-exports-has-limits.html
?scp=1&sq=Gregory%20Perry%20encryption&st=cse).

I personally believe that the FBI, or at least certain officials within the administration at that time, willingly advocated the relaxation of encryption export regulations only due to their discovery of critical vulnerabilities and weaknesses in the RSA encryption algorithm not exhibited by the predominant public key encryption method used at the time which was Diffie-Hellman. Of equal interest was RSA Security's decision to not pursue an extension of the RSA patent after its 20-year expiration, which they could have easily obtained on national security grounds. They simply waived their rights and let RSA become an open and public domain standard despite their significant revenues in licensing of the RSA encryption algorithm in the USA based on U.S. Patent 4,405,829.

If any of this conjecture is the case, then it could reasonably be said that the FBI intentionally - and very seriously - weakened the United States critical infrastructure and our military capabilities by advocating the use of a fundamentally weak encryption algorithm as a tradeoff between US National Security and their need to observe domestic communications in the United States.

Sounded implausible back then, right? Now, not so much.

Signing their key is the least Microsoft can do for using large parts of the FeeBSD TCP/IP stack in Windows.
https://lwn.net/Articles/245805/

I don't think Ken Thompson actually stuck a backdoor into Unix that propagated to other systems, but he described in a classic paper one way how it could be done using a compiler.

Not to add to the paranoia (if they were *that* interested they'd just break into your house, image your drives, and put everything back together again), some kind of backdoor almost got added to the 2.6 Linux kernel. The beauty of it was the appearance it was a simple coding error (assignment instead of comparison).

I don't trust those figures at all; First of all I can also pull a result of 86.0 and 62.3 for the RPi (which is it?). Secondly in the same source as the Celeron result there is also a 3 ghz Xeon that only gets a score of 160.8. I can find an 866mhz PIII that scores 198, which given that's almost 4x faster than your quoted result for an 800mhz Celeron (and faster even than a 3ghz Xeon) makes the figures you're using seem suspect.

They did. In short they stopped providing test cases for new features. Do not use MySQL. Period. Read more about in here.

For folk who even after RTFA wonder whats new in 3.10, the best source is probably LWN
https://lwn.net/Articles/548834/
https://lwn.net/Articles/549477/

For folk who even after RTFA wonder whats new in 3.10, the best source is probably LWN
https://lwn.net/Articles/548834/
https://lwn.net/Articles/549477/

The dm-cache device mapper target was added to the kernel in Linux 3.9. bcache is apparently on track for 3.10

One of the most interesting talks at linux.conf.au this year was by Geoff Huston of APNIC (and with a long history of involvement in the internet in Australia), talking about IPv4 address exhaustion and IPv6 and Carrier Grade NAT (and why CGNAT sucks).

tl;d[wr] version: two of the main reasons why it sucks are a) it results in double-NAT when users have their own LANs and NAT devices behind a CGNAT connection and b) it's effectively a ways for a handful of major telcos around the world to gain control of the internet on their terms, just like in their Good Old Day (which is why they have little or no interest in IPv6).

CGNAT means getting the same kind of crappy barely-functional internet service on your landline (or wifi or satellite etc) broadband service as you get on a mobile phone.

Video here:

http://mirror.linux.org.au/linux.conf.au/2013/ogv/The_IPocalypse_20_months_later.ogv

LWN article about Geoff's talk here:

http://lwn.net/Articles/424696/

The problem with "XFS" eating data wasn't with XFS - it was with the Linux devmapper ignoring filesystem barrier requests.

Gotta love this code:

Martin Steigerwald wrote:
> Hello!
>
> Are write barriers over device mapper supported or not?

Nope.

see dm_request(): /*
                  * There is no use in forwarding any barrier request since we can't
                  * guarantee it is (or can be) handled by the targets correctly.
                  */
                if (unlikely(bio_barrier(bio))) {
                                bio_endio(bio, -EOPNOTSUPP);
                                return 0;
                }

Who's the clown who thought THAT was acceptable? WHAT. THE. FUCK?!?!?!

And it wasn't just devmapper that had such a childish attitude towards file system barriers:

Andrew Morton's response tells a lot about why this default is set the way it is:

Last time this came up lots of workloads slowed down by 30% so I dropped the patches in horror. I just don't think we can quietly go and slow everyone's machines down by this much...

There are no happy solutions here, and I'm inclined to let this dog remain asleep and continue to leave it up to distributors to decide what their default should be.

So barriers are disabled by default because they have a serious impact on performance. And, beyond that, the fact is that people get away with running their filesystems without using barriers. Reports of ext3 filesystem corruption are few and far between.

It turns out that the "getting away with it" factor is not just luck. Ted Ts'o explains what's going on: the journal on ext3/ext4 filesystems is normally contiguous on the physical media. The filesystem code tries to create it that way, and, since the journal is normally created at the same time as the filesystem itself, contiguous space is easy to come by. Keeping the journal together will be good for performance, but it also helps to prevent reordering. In normal usage, the commit record will land on the block just after the rest of the journal data, so there is no reason for the drive to reorder things. The commit record will naturally be written just after all of the other journal log data has made it to the media.

I love that italicized part. "OMG! Data integrity causes a performance hit! Screw data integerity! We won't be able to brag that we're faster than Solaris!"

See also http://www.redhat.com/archives/rhl-devel-list/2008-June/msg00560.html

There's a lot more out there if you care to look.

Toss in other things like the way Linux handles NFSv2 group membership (More than 16? Let's just silently drop some!) and lots of fanbois wonder why I view Linux as little better than Windows. Hell, Microsoft may fuck things up six ways from Sunday, but they're not CHILDISH when it comes to things like data integrity.

Its pretty much impossible to install gnome2 and gnome3 on the same system, or have them both in the same repo (unlike plenty of other similar sized projects what you can have multiple versions installed (KDE3 and 4, as many GCC, python and kernel versions as you want))
https://lwn.net/Articles/466872/

mate solved this difficult technical problem, mostly by doing 's/gnome/mate/g' (since then they have modernised the code, removed most of the deprecated libraries, and added useful features)

Linux Weekly News--best signal-to-noise ratio on the whole flipping internet.

there are several ways to break DRM.
The first its to break the encryption. The CSS encryption on DVDs was weak, so to play a DVD you just brute force it.
Or you can get hold of a key. Bluray players each have a key, if you can extract one of these you can then use it to play blurays
Or you let the DRM software do the decryption, and then just capture the output. A locked down OS can prevent you from doing this, for example it can disable the screen shot function when you look at the DRM media. With an open OS and admin privileges i can always read the frame buffer.

PDF has a 'feature' to make a document un-printable. If the no printing flag is set in a file then the adobe pdf viewer will refuse to print it. some of the opensource pdf viewers have a build time options as to whether they respect this 'feature' https://lwn.net/Articles/335415/

This article has the background and links.

If they weren't rolling their own I wouldn't have bitched about them not using something already shown to work (eg. mysql and a very long list of others)

What are you talking about? According to this LWN thread, Kmail2/Akonadi does in fact use MySQL as the default backend database, though it can also use SQLite or Postgres.

Last thing is it's not really the "KDE team" doing it but instead a side project.

Akonadi is one of the main components of KDE4; its developers definitely qualify as part of the "KDE team". KMail is part of the PIM suite, again not some side project, but one of the main parts of KDE (maybe not as "main" as Kwin, but still much more close to the core of the project than, say, Gwenview).

Ha, beat this:

For personal reasons, I do not browse the web from my computer. (I also have not net connection much of the time.) To look at page I send mail to a demon which runs wget and mails the page back to me. It is very efficient use of my time, but it is slow in real time.

If you think that modern memory is simple send an address and read or write the data you are much mistaken.

Have a read of What every programmer should know about memory and get a simplified overview of what is going on. This too is only a simplification of what is really going on.

To actually build a memory controller is another step up again - RAM chips have configuration registers that need to be set, and modules have a serial flash on them that holds device parameters. With high speed DDR memory you have to even make allowances for the different lengths in the PCB traces, and that is just the starting point - the devices still need to perform real-time calibrate to accurately capture the returning bits.

Roll Serial Port Memory Technology!

It appears we've hit the problem of the person who is dismissing X out of hand does not actually understand why people use it, which I suppose it why your suggestions have failed to address the questions.

I'm not dismissing X out of hand. That would be a straw man. What I am saying is that it clearly impacts on the local desktop performance (and it's not hard to find comments by leading X devs who state this for a fact). And most of the objections raised for switching to something more efficient concern a feature that not many people use, and even if Wayland were to become the default experience, could be achieved anyway.

Anyone who absolutely cannot abide the change can just use an X11 fork, or vnc / MX / X over Wayland or scratch the itch and implement in Wayland what they perceive to be missing.

Will LWN close down too? [lwn.net]?

Doubtful. LWN has a monetization strategy which appears to be working.

I liked Happy Penguin, what's next? Will LWN close down too?? I suppose for a lot of us The LInux Game Tome was important because they listed lots of games for us, and have a pretty good interface at that. Guess I just miss the old wide open days of Linux..

*Goes out and and stands in yard with a torch and pitchfork*