Slashdot Mirror

That said, what I miss in git is the "version history" of commits.

I love git and use it everyday, but I'm not sure I understand 5% of it.
That said, I think https://www.kernel.org/pub/sof... could help you.
git rev-list --all --pretty=oneline

The GPL only applies to distribution. AFAIK you can install any software of any license of your liking in your computer.

Kernel tainting isn't a legal thing, it's one of the kernel sysctls(the 'tainted' section). One of the ways to cause nonzero taint is with a non-GPL kernel module; but various other categories of "If you are doing one of these things, we don't want to hear your damn bug report because it is likely to be hopeless and/or not our problem" also have taint codes.

You are still free to do things that taint the kernel; but if something has a taint code, there is a strong suggestion of 'not recommended, on your own head be it'.

Sorry to hear about that. Probably a good idea to file a bug report at https://bugzilla.kernel.org/ (if you didn't already).

btrfs brings really useful features like data integrity protection through the combination of checksums with either multiple copies or error correction codes*, snapshotting** and the ability to create a logical copy of a file without creating a physical copy. These are features that most other linux fileystems don't have. You can find out more at https://btrfs.wiki.kernel.org/...

Unfortunately it's hard to take a filesystem, particularly a complex one like btrfs from "seems to work fine under our lab tests" to "proven stable in production" . devs need data from real world problems to improve the filesystem but to get data from real world problems requires people to run it on real world systems but people are reluctant to put an experimental filesystem on their production servers.

This is good news towards the goal of turning btrfs into a "proven stable in production" soloution.

* The trouble with conventional raid is it keeps multiple effective copies but it has no idea which of those copies is correct. So it relies on the underlying drives to return either correct data or an error code. Experiance has shown that the checksum systems built into drives are not strong enough to completely prevent bad data from being returned.
** Yes you can do snapshotting with a layer like lvm between the filesystem and the storage but there are distinct advantages to doing it as part of the filesystem.

LOL, nice! Or ...

* Broken To Read Free Space
* Broken Treatment Reading Free Space

btrfs FAQ 4.4 - 4.8
* 4.4 Why does df show incorrect free space for my RAID volume?
* 4.5 Aaargh! My filesystem is full, and I've put almost nothing into it!
* 4.6 Why are there so many ways to check the amount of free space?
* 4.6.1 Raw disk usage
* 4.6.2 Actual data
* 4.7 Why is free space so complicated?
* 4.8 Why is there so much space overhead?
https://btrfs.wiki.kernel.org/...

--
Microsoft Windows 8: A 64-bit compilation of 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor written by a 2 bit company that can't stand 1 bit of competition with 0 bit of understanding good UI.

While all the hipsters were using Btrfs, the real geeks were using ZFS and not worrying about bad designs such as the inability to query free space ...

https://btrfs.wiki.kernel.org/...

I've been using btrfs on all my machines/laptops for more than 2 years now. I've never had corruption or lost data (btrfs has actually coped rather well with failing/dying disks in my experience), unlike ext4. COW, subvolumes and snapshots are nifty.

But too many times I've had the dreaded "no space left of device" (despite 100GBs remaining) when you run out of metadata blocks. The fix is to run btrfs balance start /volume/path - I now have a weekly cron job on my non-SSD machines - but it's hugely inconvenient having your machine go down because you're expected to babysit the filesystem.

Recent months of Docker usage has made me encounter this condition twice this year already.

I'll continue using btrfs because I've experienced silent corruption with ext4 before which I believe btrfs would have protected me against, and I like snapshots and ability to test my firmware images cheaply with cp --reflink pristine.img test.img.

Fortunately, for some values of device and OS, you can still find such documents online. They've just become too large to print and ship with the devices.

Lets see here:

You've got the PREEMPT_RT patch which makes the Linux kernel fully preemptible.

Then you've got the RTLinux extension which runs Linux within a hard real-time hypervisor.

Nope. It's definitely impossible to do real-time work with Linux.

RTOS implies determinism, the ability to execute things in a timely manner. That means prioritizing interrupts and allowing high priority threads and processes to preempt the kernel and other core OS processes or threads. Many people mistake real time for processing something as it arrives into the computer e.g. a near latency free video image on screen from a camera or reading a stream of GPS coords from a serial port. Lets go with the camera example. While this sounds like real time, there is no software or hardware that guarantees that the image software and camera driver will always deliver an image to the screen in a guaranteed and timely manner. For example if you start the camera application and you play a video game, does the "realtime" video application retain its low latency? Or will it stutter as its process fights for CPU time with the video game process as the OS sees fit? In a true RTOS, the video software AND driver TELLS the OS their priority and the OS obeys. They can be assigned a high priority so any other software will have to wait until there is spare CPU time.

Linux has two routes to achieve this:
CONFIG_PREEMPT_RT
Patches to the Linux kernel which removed the various locks in the kernel (aka big kernel lock) which allows a process to be prioritized over the kernel itself. IRQ's are also prioritized. You can run various processes and assign them a priority.

Xenomai
Xenomai is a dual kernel approach where a vanilla Linux kernel is patched with Xenomai. It creates a separate kernel that allows its processes to preempt the Linux kernel and takes over handling interrupts through the I-pipe. This means all interrupts are handled by the Xenomai kernel and if an interrupt is destined for the Linux kernel, Xenomai passes them as a virtual interrupt. Xenomai also features its own HAL allowing hardware to be dedicated to Xenomai processes via RT drivers. You can also do things like dedicate a processor core to a specific task to guarantee there is ample CPU time. And Xenomai has a neat little trick, its kernel is a nucleus which can run various "skins" which are API's; e.g. you can use RT code using Native, POSIX, uITRON, VxWorks and a few other RT API's.

YMMV but both solutions have tradeoffs. There is a paper published (https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf) which compares the two popular Linux RT solutions. Preempt_rt is easier to implement as it is part of the mainline kernel, you only need to include a few headers and some gobals to define the process priority. But in tests it shows higher timing jitter than Xenomai. If you want maximum performance, then you need to look into Xenomai which requires a bit more setup, patching and using the various API's and RT hardware drivers.

BTW, Windows also has RT dual kernel systems. So yes even windows can be an RTOS. Look up Ardence RTX and INtime.

What is being done to improve the Linux Kernel documentation in both structure and completeness?

A good white paper was already written about what needs to be improved and yet the mailing list discussions are just endless bike shedding. Here is the white paper:
https://www.kernel.org/doc/ols... There appears to be no person who the buck stops with. Furthermore based on 3 years of reading the mailing list I seriously doubt more than 2-5 people on the mailing list actually understand what good documentation is, let alone how to write it.

It is now official. The Università degli studi di Milano has confirmed: Linux is dying.

One more crippling bombshell hit the already beleaguered Linux community when UNIMI confirmed that Linux's flagship domain, kernel.org, fell to a shocking #1797 in the Common Crawl rankings. You don't need to be the Amazing Kreskin to predict Linux's future. Its domain now ranks just behind Excite.com, the now-irrelevant search engine from the 1990s, which edges it out at #1796.

The glaring gap between Linux's ranking and the rankings of those in the vibrant, enterprise-ready world is in itself embarrassing enough: Apple #8, Microsoft #17, even Oracle #248. But what seals the coffin is that Linux has fallen behind even the notoriously moribund FreeBSD operating system in these industry-leading metrics, trailing it by nearly one thousand, five hundred positions.

At the Toronto Linux Users Group I heard a story about how the parking meters used to crash because some setting would randomly kill processes when Linux was running low on memory.

That's probably the Out of Memory handler in Linux. It's not exactly random, the OOM handler ranks processes by "badness" and prefers to kill off newer processes that are using a lot of memory before going to older, long running processes.

There's a sysctl.conf setting that will tell the kernel to panic and reboot in an OOM condition instead of trying to kill off enough processes to continue running, which is probably would be better for an unattended parking meter.

They handle it with this.

Those bugs and glitches are addressed as quickly and efficiently as any other OS addresses their own bugs and glitches.

But they aren't. They sit in the distro's bug tracker forever, with the occasional unhelpful "have you tested the latest release if the bug is still present" and the bug ultimately just expires due to no activity.

That last one? Updating the kernel disables the keyboard? That's pretty serious. Something one would expect from Apple, LMAO!! The rather simple workaround, however, is to select the older kernel, where the keyboard did work. Presuming, of course, that the machine is configured so that selection of kernels is possible.

Yes. The keyboard bug is tracked in mainline now and I personally did a kernel bisect and pinpointed out the particular commit which causes the bug. The result? Crickets chirping.

You mean like practically everyone?

Not quite like everyone, stupid.

Which version of the kernel and btrfs-progs are you using? Some distros are still shipping ancient versions of the userspace tools, like 0.19 or 0.20. The latest is 3.12 (they recently started using the kernel version instead), so you may want to try compiling it from the source.
The two most helpful commands I've found are 'mount -o recovery', which can restore the superblock if it's missing/corrupted, and 'btrfs check --repair' (formerly btrfsck). Note that check doesn't actually fix the errors it finds without that flag, unlike fsck. If you have a multi-device file system, trying to mount one of the other drives can help, since copies of the metadata are stored on all of them (RAID1 style).
If that doesn't work, you can often get the data off by mounting it as readonly, or by using 'btrfs restore'.

Btrfs used to be quite buggy, but these days I've found it to be pretty stable and reliable. That only applies if you're using the latest packages though - otherwise, you might as well be using it back in the early days.

Linus is reasonable guy. He's sometimes wrong, but can be convinced with technical arguments. The "don't-trust-RDRAND" change was included in Linux a year and a half ago: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9

BTRFS needs to become the Linux default FS.

I just lost my wife's BTRFS partition yesterday after a hard-reset. Consulted Google for btrfs repair options and discovered they are lacking. Kept reporting root->node assertion failed, whatever that's supposed to mean. I don't recall the last time I've lost a partition like this, I assumed fsck would have done the trick.

See https://btrfs.wiki.kernel.org/index.php/Btrfsck :

Note that while this tool should be able to repair broken filesystems, it is still relatively new code, and has not seen widespread testing on a large range of real-life breakage. It is possible that it may cause additional damage in the process of repair.

Perhaps someday dm-cache will make it into mainline.

dm-cache is in mainline since 3.9. Now please test it and let me know if I should bother trying it!

https://www.kernel.org/doc/Documentation/device-mapper/cache.txt
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6b4fcbad044e6fffcc75bba160e720eb8d67d17

Perhaps someday dm-cache will make it into mainline.

dm-cache is in mainline since 3.9. Now please test it and let me know if I should bother trying it!

https://www.kernel.org/doc/Documentation/device-mapper/cache.txt
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6b4fcbad044e6fffcc75bba160e720eb8d67d17

https://www.kernel.org/doc/Documentation/CodingStyle

and here is a list of the docs for all the subsystems:

https://www.kernel.org/doc/Documentation/

You should probably give up if you couldn't find these.

"Understanding the Linux Kernel" is a nice book that gives you a high level view.

The kernel is a constantly moving target, keeping up newbie friendly docs is pointless.

You aren't going to learn the entire kernel anyway. Take a small and relatively simple subsystem: the code for TCP or Ext4 for example, and start there.

Of course the first thing you should learn is how to compile and test the kernel.

https://www.kernel.org/doc/Documentation/CodingStyle

and here is a list of the docs for all the subsystems:

https://www.kernel.org/doc/Documentation/

You should probably give up if you couldn't find these.

"Understanding the Linux Kernel" is a nice book that gives you a high level view.

The kernel is a constantly moving target, keeping up newbie friendly docs is pointless.

You aren't going to learn the entire kernel anyway. Take a small and relatively simple subsystem: the code for TCP or Ext4 for example, and start there.

Of course the first thing you should learn is how to compile and test the kernel.

Posting as AC to preserve mod points, I searched and found http://kernelnewbies.org/Documents which you probably know. That is referenced by https://www.kernel.org/doc/Documentation/HOWTO as a resource for kernel developers. Unfortunately it looks like a dying site. The last edited date in the footer is old for many pages. The list of Up To Date Books include stuff published in 2005 or about kernel 2.6.
Probably Linux need a Linuxpedia and developers should at least explain their code there.
However there are plenty of contributors so I'm quite sure there is a way to get up to speed.

The prevalent attitude seems to be 'The code is there for you to modify. Do it yourself.' For the average user, that could mean developing proficiency in some programming language, familiarity with that software's architecture before they even begin to understand how to get what they want.

Making matters worse...most open-source projects are severely under-documented. Even though the source is available, getting past the hurdle of severe under-documentation is too much of a hassle. It takes dedication to get to the point where one can contribute meaningfully to an open-source project, and not for any good reason — it shouldn't take that much effort.

Making matters even worse...in my experience, most open-source-project maintainers will resist documentation. I just went through this with an open-source project I've been interested in a long time. Since the source-code had practically no comments whatsoever, I took it upon myself to learn the subject matter (in this case, NOT an easy task), then learn large parts of the source code. Then, being the sort that's willing to contribute, I offered to document the code. The maintainer was willing, even eager, for it. Then I submitted my first patch...and he immediately changed his tune. He found my documentation to be "excessive", and quoted chapter 8 of the Linux kernel coding guidelines to bolster his case. Frankly, I couldn't disagree more with his viewpoint.

I'll never understand, for the life of me, why programmers don't document their source code, especially open-source programmers. How is anyone supposed to contribute to their project if the hurdle is set so high? Hell, how do they remember how a piece of code works if they haven't seen it in a long time? It boggles the mind.

I don't have any good theories for why this is...just a disparaging one. Every time I encounter this problem, I get a vivid image of Gollum grasping some source-code printouts and hissing "Nooooo! My preciousssssss...."

I certainly document my open-source code. My biggest project to date is a temporal analog-video denoiser called y4mdenoise. Feel free to look at the code, if you'd like to see an example of what I'd consider a proper level of documentation. Start with the high-level overview and find out for yourself.

I would think you could easily discover corruption in BTRFS since it has checksums.

And if you're going to complain about that, then you should use rdiff-backup over just rsync w/ links because rdiff-backup stores a checksum (SHA1, I think) along with the file data.

There's also switches to force rsync / rdiff-backup to examine the entire file instead of just the size and mtime.

JIT is generic in a sense that each program (and even different parts of a single program) is different and you cannot base them all on a common framework. E.g. in C++ sometimes you have to abandon STL at all because you cannot allow dynamic memory allocation (and memory fragmentation it causes). I wouldn't say that "Java performs as well as C++", unless you are speaking about UI-heavy programs where bottleneck is user input - or, alternatively, C++ programs written by people who don't know how CPUs implement a virtual method call and why it's slower than a non-virtual one.

Yeah, with native languages you are bound to a specific architecture (and even variations of it, e.g. AVX, SSE), but is it better to be a jack of all trades and master of none? And also, there's no "explosion of binaries" anymore - unfortunately, the number of architectures available is continuously shrinking (kind of undermining that design goal of Java). "Boring" native software that is not performance-tuned may very well ship just a generic binary targeted at, say, all Pentium IV and higher CPUs.

Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance. That is also the reason why Java can be used server-side without much problems, too. However, once you bring it to desktop, where performance matters, it starts to suck immediately. That's not a problem of Java, though, but all managed languages - .NET also sucks. Microsoft tried to build an OS which would be .NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native :)

Sure, when I'm forced to use Java (e.g. Android), I immediately use the JNI window to escape. I am not interested in "benefits" of Java, if it means that I need to waste even more time trying to profile the application. Is there any low-level Java profiler, by the way, which would tell where CPU is burning cycles in your code at? Down to the level of assembly - i.e. something like perf annotate.

"Why are you defining "Linux" as just the kernel? The original meaning was the entire OS, with the phrase "Linux kernel" referring to just the kernel."

If you really want to know what is actually Linux, here is the link. It doesn't actually matter what it was first called, but you are wrong. It was actually first called: a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.

"I'd advise ignoring the last two options and calling the OS by it's original name-- Linux."

Again, it would be awesome advice if that was the original name in the first place. It wasn't.

Flash forward to today. Linux is the kernel. You can use git to get Linux as follows git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git See. It's not called linux-kernel.git, just linux.git. (don't be confused by the kernel.org domain name. As it turns out there is lots of stuff not related to the kernel on kernel.org and lots of domains without kernel in the name where you can get the linux source, which again, contains the kernel)

To make an OS you need user space tools, and you cannot make an OS using only Linux and the util-linux user space tools. Period.

there are too many bugs in btrfs for it to be installed in production:
https://bugzilla.kernel.org/buglist.cgi?component=btrfs

Well, hold on a second here...

Your list shows 196 bugs with only 36 still un-fixed.
Yet EXT4 shows 214 bugs with still 34 still un-fixed.

Yet Ext4 seems to by adopted by world plus dog.

there are too many bugs in btrfs for it to be installed in production:
https://bugzilla.kernel.org/buglist.cgi?component=btrfs

especially this one, which has yet to be resolved:
https://bugzilla.kernel.org/show_bug.cgi?id=60860

which is a major useability issue. yes i made the mistake of installing btrfs on a live production system.

there are too many bugs in btrfs for it to be installed in production:
https://bugzilla.kernel.org/buglist.cgi?component=btrfs

especially this one, which has yet to be resolved:
https://bugzilla.kernel.org/show_bug.cgi?id=60860

which is a major useability issue. yes i made the mistake of installing btrfs on a live production system.

Hmm, that's a cool log actually. I browsed that a bit and there's a funny patch where someone corrects typos of HDMI being written "HMDI".

It's good they fixed this.

the read-onlyness was only a part of that complaint, although read-only snapshots helps, it's sill more unwieldy for the most common usages of them, and inconsistant with what you would expect from snapshots from other filesystems (other then ZFS). Keeping snapshots seperate makes it far more clear to the user what is going on (particularly when using them in a automated snapshotting config).

At the vary least df still does not work as expected

You're not seeing much work being done because you're NOT looking where you should: you're looking at the btrfs-progs git repository which are tools to manage btrfs... So yes, no that many commit in there...

The real kernel repo is here:
Chris Mason's BTRFS tree

Here's the log of commit targeted at Linus:
For Linus

It's probably easier to just track Linus' tree:
Linus' tree: fs/btrfs

Look at that: people are working on it...

You're not seeing much work being done because you're NOT looking where you should: you're looking at the btrfs-progs git repository which are tools to manage btrfs... So yes, no that many commit in there...

The real kernel repo is here:
Chris Mason's BTRFS tree

Here's the log of commit targeted at Linus:
For Linus

It's probably easier to just track Linus' tree:
Linus' tree: fs/btrfs

Look at that: people are working on it...

You're not seeing much work being done because you're NOT looking where you should: you're looking at the btrfs-progs git repository which are tools to manage btrfs... So yes, no that many commit in there...

The real kernel repo is here:
Chris Mason's BTRFS tree

Here's the log of commit targeted at Linus:
For Linus

It's probably easier to just track Linus' tree:
Linus' tree: fs/btrfs

Look at that: people are working on it...

Nice FUD there. You picked the btrfs-progs, which are the userspace tools, not the actual btrfs filesystem driver.

http://git.kernel.org/cgit/linux/kernel/git/josef/btrfs-next.git/log/

and it'll be as good / better than ZFS soon

No. Sorry.

There hasn't been a commit to the official BTRFS tree in over two months. There have only been five distinct contributors during the entire third quarter. The second quarter saw only 70 commits.

That pace is way too slow for a file system with so many 'to be implemented' features. While not dead, at this rate BTRFS will never surpass ZFS in any notable way.

I'm sincerely sorry about that. Linux contributors just aren't getting it done wrt BTRFS, and that's a crying shame; other operating systems should look on in envy at marvelous Linux file systems.

And yes, I should be in there plugging away at it. So should you. But we're not.

That's not Oracle's fault, either. People just don't care enough to put in the effort. We're just here griping about Oracle and the ZFS license issue and poasting about BTRFS being the answer, waiting for someone to do all that brutally hard work.

We're deluding ourselves.

Yes, it was:
Quoting Linus: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'".

Since there is no way to inspect the random number generator and no way to verify it's operation, it should not be used by default.

Even if it is only used as a way of increasing the entropy of a random number generator not to exclusively provide the result?

You should go and read this:
https://linux.slashdot.org/comments.pl?sid=4191765&cid=44811495

and this:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9

As shown here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9

It's part of the pool.

Not true... I have no opinion either way, but it's entirely possible to have a very good understanding of how semi-random numbers affect cryptography, and also of how rdrand generates them, without having the programming background to be able to safely remove it from the kernel. Crypto is about math, not programming, and contrary to popular opinion (apparently), the two do not always go hand-in-hand.

RdRand could generate entirely non-random numbers and it still wouldn't make the output of /dev/random any less random. It's designed so that additional inputs can only increase the entropy, never decrease it. There's a danger if you over-estimate the amount of entropy that a particular input adds to the pool, but the bits mixed in from rdrand don't increase the entropy counter so that's not a problem in this case.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9

That's correct. Here's the diff: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Makefile?id=ad81f0545ef01ea651886dddac4bef6cec930092.

Note that the previous version, 3.10, was named "Unicycling Gorilla". The fact that you probably had no idea it was named that shows just how important these release names are. :)

3.10 is the next LTS kernel by Linux standards. The existing long term kernels are 2.6.32 (as used in RHEL6, Debian Squeeze, Ubuntu LTS 10.04), 2.6.34, 3.0, 3.2.50 (used in Ubuntu 12.04 LTS), and 3.4.59.

Well, point four isn't completely true. As with many distributions, the kernel contains non-free (or at least potentially non-free) firmware blobs, a list of which can be found here.

Well then good thing the Linux kernel isn't licensed under the GPL. It's licensed under a modified GPL allowing for binary drivers.

Stop spreading misinformation. There is no exception for binary drivers. There is a clarification that the kernel copyright "does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of 'derived work'." User programs; not drivers. Otherwise it's stock GPLv2.

Here's the actual license so you can see for yourself.

A few companies like nVidia get around this by never distributing the drivers with the kernel. In nVidia's case, they use the same driver for Windows and Linux, so they can also argue that there is nothing Linux-specific about the part they're distributing. Even so, many see this as a grey area. The Android case is completely different, both because these are Linux-specific drivers and because they are being distributed with the Linux kernel on the same media as part of a complete operating system. This is just as much a violation of the license as distributing a closed-source program which depends on a GPL library.

I value something that doesn't require a license, whether you're running a free "e-reader" on Linux, there's probably the only thing that won't have much in the way of tangible strings but even Linux has dropped the 386 processor from support.

Yet Linux still runs just fine on 386 processors; just not the current versions. Here: https://www.kernel.org/pub/linux/kernel/v2.4/

Just like sharing music? Or sharing copyrighted material that the MPAA considers theirs if you somehow copy it to another format? Ever here of thePirateBay? Just ask Kim DotCom how it feels to host material in an electronic form. You think the Supreme Court has your best interests at heart? All it takes is the right justices or the right set of laws and your rights are gone here in the US and it's getting worse every year. The Media distributors and publishers are a huge lobby in this country pushing what is and isn't fair copyright and it will get to the point that they'll push for single use e-books that you can't own, share or read more than once unless you're willing to keep paying for it.

Breaking DRM != sharing content. It's a completely different kettle of fish. In particular, it happens only inside your machine, instead of being broadcast to the whole world.

As for the Supreme Court, as a I said, I'm not under their jurisdiction. But they did vote for the student selling textbooks, in detriment of the copyright holders.

How long do you think it will take for e-books to get the same treatment as a movie or a piece of music.. "It was distributed electronically." Therefore some intermediary who owns the rights will go after somebody for downloading an e-book they didn't pay for that "wasn't free." Unless Authors are willing to give their stuff away royalty free, just like some musicians are doing or selling it and saying it's "yours" then you can say it's yours but the lines are getting blurry.

As I said, I don't care. I wipe my ass to their claims that I don't own it.

Again on an operating system that's not tracking you? Linux perhaps? Good, that's an alternative perhaps but again, I consider that transient, more transient than good old fashioned bound (as in book binding). Call me old fashioned but that way if I lose it, it's because of something that I did or perhaps someone overtly did or by accident, not because some company or someone with less than stellar motives took it from me using a license model, yes "free" books aside but 9 times out of 10 you're reading those probably on an O/S that will track your habits and report them back to somebody. It's not fiction, it's a fact now unfortunately. Reading that on an iPad? Guess again.. http://gizmodo.com/5951173/apple-is-tracking-you-again-in-ios-6-and-how-to-turn-it-off

Calling ebooks bad because some particular readers are bad is like calling paper books bad because some publishers use rubbish paper.

I specifically mentioned readers with no networking, so mentioning the iPad is specious at best.

Call me old fashioned, but anything electronic is transient. Your jpegs, your images. Yeah you can back them up certainly but unless you keep upgrading or shifting with the digital times, it'll become so much like the Betamax or MFM or RLL hard drives.

The physical storage is transient; the content isn't. Conflating the two is misleading.

Yes, you need to upgrade, but you're on Slashdot, so clearly you use computers, so you need to upgrade them anyway.

Maybe yes, maybe no but I don't want anybody to know what I read or why I read it. It's none of their fucking business. Again, I don't want to have to worry about battery life sometimes or form factor or bookmarking something electronically or covering

Considering it's open source, it's not terribly difficult to verify the veracity of the article.

https://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv3.x%2Ftesting%2Fpatch-3.11-rc1.xz;z=367

I can attest to the lack of backdoors in SELinux. I am the SELinux maintainer. I'm the guy responsible for it.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n7166

I work for Red Hat. Not for the NSA. SELinux code does not go from me through the NSA, it actually goes the other way around. The NSA asks me to put code in the Linux kernel and I pass it to Linus. I have reviewed each and every line at one point or another.

The NSA may have some magic backdoor somewhere in the Linux kernel, but I'll stake my name that it isn't in the SELinux code.

So, not that I doubt your understanding of the code or your intentions on keeping it secure, but is it viable that NSA-email-holding "M: Stephen Smalley <sds@tycho.nsa.gov>" has enough to do with the code to submit something nefarious that went unnoticed? Asking for a friend.

I can attest to the lack of backdoors in SELinux. I am the SELinux maintainer. I'm the guy responsible for it.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n7166

I work for Red Hat. Not for the NSA. SELinux code does not go from me through the NSA, it actually goes the other way around. The NSA asks me to put code in the Linux kernel and I pass it to Linus. I have reviewed each and every line at one point or another.

The NSA may have some magic backdoor somewhere in the Linux kernel, but I'll stake my name that it isn't in the SELinux code.