Slashdot Mirror

I find some of the current file systems to be adequately reliable. Even their performance is acceptable. But, the Linux systems are lacking.

Is there a reliable Linux file system such as EXT4 that has an easy to use copy on write(CoW) feature to allow instant recovery of any file changed at any time?

NILFS2 provides continuous point in time snapshots, which can be selectively mounted and data recovered. Not quite as instant recovery as your use case examples, but it's only a few commands/wrapper scripts away.

> a modern COW filesystem with checksumming, compression, multiple devices, caching, and eventually snapshots and all kinds of other nifty features

Instead of yet another FS flavor of the month, or year, (Reiserfs, Btrfs, Bcachefs, etc.) and all the man-hours wasted re-solving the same old problems how about just doing it right the first time (ZFS) ?? Because this is what it is turning into. What advantages bachefs have over ZFS??? There is no way in hell I'm going to trust an unproven, buggy, and incomplete FS when we already have one that works.

Fixing the Butr free space shenanigans would have been a step in the right direction: An existing debugged FS.

Reminds me of this xkcd #927: Standards

MSG:

Thanks for the additional information. None of this is readily available in the first links for Ubuntu, zswap, or Linux, and the items I quoted are either current documentation or statements from 6 months ago--so I expected them to be accurate. In addition, the current kernel documentation of zswap STILL lists it as experimental:
https://www.kernel.org/doc/Doc...

That said, given this info, many of my earlier points were incorrect. I just enabled it on for my downstairs desktop. It's still not enabled by default on either Ubuntu or Redhat, but at least it's a reasonable effort to turn on--no kernel recompilation, etc.

What you want is zram, not zswap. ... zswap is about compressing the swap file

Not according to the documentation.

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

[Zswap] takes pages that are in the process of being swapped out and attempts to compress them into a dynamically allocated RAM-based memory pool.

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

Modern OSes use a pagefile, eh?

That seems to say exactly opposite.

In Linux, suspend to disk really does write the contents of RAM to the swap partition.

From here:

Suspend part
            ~~~~~~~~~~~~
            running system, user asks for suspend-to-disk

            user processes are stopped

            suspend(PMSG_FREEZE): devices are frozen so that they don't interfere
                                        with state snapshot

            state snapshot: copy of whole used memory is taken with interrupts disabled

            resume(): devices are woken up so that we can write image to swap

            write image to swap

            suspend(PMSG_SUSPEND): suspend devices so that we can power off

            turn the power off

That list is well out of date. The most recent version is here.

== Size == * If the source code also exceeds 100 MB when it is compressed [ +5 points of FAIL ] 125372299 Jul 22 00:36 linux-4.1.3.tar.gz

FAIL. linux-4.1.3.tar.xz 22-Jul-2015 00:36 79M [ -5 points of FAIL]

== Source Control == * You've written your own source control for this code [ +30 points of FAIL ]

FAIL Like quoting the largest archive choice for the source code, you choose the wrong meaning of "own". That's not the meaning implicit in Tom's list - nor does it fit his reasoning (using an obscure versioning system limits use and development).
"There is no publicly available source control (e.g. cvs, svn, bzr, git)" . [ -30 points of FAIL]

== Building From Source == * Your source is configured with a handwritten shell script [ +10 points of FAIL ]

FAIL. It's not handwritten. It could be. There's difference. [ -10 points of FAIL]

Even worse: handwritten C program: scripts/kconfig/mconf.c that is compiled and run by "make menuconfig".

FAIL, most source code is handwritten. C source is not a script

== Libraries == * Your code only builds static libraries [ +20 points of FAIL ]

FAIL Demonstrably Linux supports dynamic libraries and can (often is) built without static libraries only. [ -20 points of FAIL]

* Your source does not try to use system libraries if present [ +20 points of FAIL ]

FAIL. Unless you can produce a citation that shows that Linux will try and use system libraries when the same libraries have been statically compiled (yes, even glibc). [ -20 points of FAIL]

== Code Oddities == * Your code depends on specific compiler feature functionality [ +20 points of FAIL ]

FAIL. If that were the case gcc would be the only possible compiler. It's demonstrably not. [ -20 points of FAIL]

== Licensing == * Your code does not have per-file licensing [ +10 points of FAIL ]

FAIL. Unless you've got a citation for that. I'm sure M$ would love to hear of this invalidation of the kernel license. [ -10 points of FAIL]

=== FAIL METER === Total: 180, highest possible: 135+ points of FAIL: So much fail, your code should have its own reality TV show.

Let me fix that for you:-
=== FAIL METER ===
20 points of FAIL
5-25 points of FAIL: You're probably doing okay, but you could be better. (um, maybe Linux is doing OK - one of two people use it)

Your score:-
=== FAIL METER ===
115 points of FAIL
95-130 points of FAIL: HONK HONK. THE FAILBOAT HAS ARRIVED!

Is Edge going to be portable to non Windows operating systems like GNU/Linux, FreeBSD, Solaris, OS X, HP-UX, OpenServer X, Haiku OS, AIX, Android and Firefox OS?

You must feel so smart listing all those UNIX operating systems. You know so many!

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)...

Is Edge going to be portable to non Windows operating systems like GNU/Linux, FreeBSD, Solaris, OS X, HP-UX, OpenServer X, Haiku OS, AIX, Android and Firefox OS?

https://bugzilla.kernel.org/sh...

Dear Mr. Torvalds,

what are your steps towards achieving gender equality among the subsystem maintainer group? Why haven't you introduced a 50% female quota yet, to encourage females to start programming? Also, why haven't you considered naming a benevolent dictator-ess for life, so that the dictator leader role isn't solely occupied by a male?

Sincerely,
a deeply convinced SJW

Not quite yet - still on 4.1-rc6, final version not yet released.

(At least as far as kernel.org is concerned).

Correct!

Not quite yet - still on 4.1-rc6, final version not yet released.

(At least as far as kernel.org is concerned).

https://kernel.org/pub/linux/k...

md raid. The bug was in commit md/raid0: fix bug with chunksize not a power of 2 causing, you guessed it, a bug with a chunksize not a power of two. I guess "fix" was a bit diversionary.

The real problem was a macro modifying arguments that were later expected to be the unmodified version.

There seems to be a fix in RAID code and a fix in Ext4 code.

The latter was incorporated in Linux 4.0.3 (changelog), and according to the Phoronix article the RAID bug is still unfixed.

There seems to be a fix in RAID code and a fix in Ext4 code.

The latter was incorporated in Linux 4.0.3 (changelog), and according to the Phoronix article the RAID bug is still unfixed.

Vivid Vervet ships with 3.18.3 rather than a modern 3.18 such as 3.18.12, which seems unconscionable.

In particular, there's a known regression where BTRFS fails to clear it's logs and the system become unbootable. This gotcha seems to take around two weeks to manifest, at which point the kernel will lock. https://btrfs.wiki.kernel.org/...

Well, you saw that behavioral policy linus committed to the docs directory, right?

https://git.kernel.org/cgit/li...

The sjws have been placated, but as we know, enough is never enough for them.

This doesn't pass the sniff test. This 'bug' has apparently been around for months (October/November) and it's just now that people are noticing? And the fix is patching the kernel rather than regressing whatever change was in Chrome that added this?

The change is an improvement to sandboxing (i.e. security). If the kernel patch was sufficiently minor (this appears to be the case), it makes far more sense to backport it (improving the security under older kernels) than to remove it (compromising security under newer kernels). This is especially true given Debian's focus on security.

Most of the comments in the thread seem to be from people who don't care, but are happy to use it as an opportunity to bash Chrome/Chromium. I suspect if someone had actually done the work of writing a patch, it would have been merged without much drama.

Here is the kernel commit message:

seccomp: implement SECCOMP_FILTER_FLAG_TSYNC
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply permissive programs prior to process start up, it is
difficult to further restrict the kernel ABI to those threads after that
point.

This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for
synchronizing thread group seccomp filters at filter installation time.

When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC,
filter) an attempt will be made to synchronize all threads in current's
threadgroup to its new seccomp filter program. This is possible iff all
threads are using a filter that is an ancestor to the filter current is
attempting to synchronize to. NULL filters (where the task is running as
SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be
transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS, ...) has been set on the calling thread, no_new_privs will be set for
all synchronized threads too. On success, 0 is returned. On failure,
the pid of one of the failing threads will be returned and no filters
will have been applied.

The race conditions against another thread are:
- requesting TSYNC (already handled by sighand lock)
- performing a clone (already handled by sighand lock)
- changing its filter (already handled by sighand lock)
- calling exec (handled by cred_guard_mutex)
The clone case is assisted by the fact that new threads will have their
seccomp state duplicated from their parent before appearing on the tasklist.

Holding cred_guard_mutex means that seccomp filters cannot be assigned
while in the middle of another thread's exec (potentially bypassing
no_new_privs or similar). The call to de_thread() may kill threads waiting
for the mutex.

Changes across threads to the filter pointer includes a barrier.

https://git.kernel.org/cgit/li...

Well, if you don't want the kernel to kill your process immediately, you have that option too. Read the fine manual. Personally I consider it a zombie apocalypse "promise to shoot me if I turn" kind of pact though. Would you really want a process to continue if the most plausible explanation for a syscall that it wasn't supposed to make is that it's executing injected code? The parent process should obviously make a note of its child's demise and the cause.

.. after extensive statistical analysis of my G+ polling, I've come to
the inescapable conclusion that internet polls are bad.

Big surprise.

But "Hurr durr I'ma sheep" trounced "I like online polls" by a 62-to-38%
margin, in a poll that people weren't even supposed to participate in.
Who can argue with solid numbers like that? 5,796 votes from people who
can't even follow the most basic directions?

In contrast, "v4.0" beat out "v3.20" by a slimmer margin of 56-to-44%,
but with a total of 29,110 votes right now.

Now, arguably, that vote spread is only about 3,200 votes, which is less
than the almost six thousand votes that the "please ignore" poll got, so
it could be considered noise.

But hey, I asked, so I'll honor the votes.

Source

Part of the problem is, the examples are really too small to call either way.

Interestingly enough, I recently took a peek at one of Linus' latest patches (regarding the OS' ability to patch without rebooting), and examined the use of goto in that code. This is "real world" code, and saw three uses of goto, and each one seemed perfectly reasonable and easy-to-follow.

I am affected by this bug, but can't seem to find any real place to follow it. I searched https://bugzilla.kernel.org/ but that didn't turn up anything. Anyone know where the source of truth for tracking this issue might be located?

yes:

http://lkml.iu.edu/hypermail/linux/kernel/1411.3/04672.html/

https://bugzilla.kernel.org/show_bug.cgi?id=85941/

Although there are some ways to secure DMA (like a white list of addresses/sizes that are safe to write to), all of the advertised functionality of USB3, such as the sustained data rates, would be very hard to achieve if you didn't have direct access to memory

Sigh. It's almost like slashdot is peopled by people who know fuck-all about computers, such as the existence of the IOMMU. Decent operating systems have support for these. They completely solve this problem with minimal overhead.

That's why Firewire ruled for live streaming of data for so long: DMA made it's rates reliable

Yes, firewire has the same problem, and the same solution.

Clearcase sucks for Java. Anything else sucks for C/C++. Don't even consider Clearcase if you're an Eclipse shop. Don't even consider doing serious C++ job on Git. Just use the right tool and move on.

So... you're saying that anyone using git for a serious C project is an idiot? Hmm...

Containers are an interesting beast. Solaris has had Zones (aka containers) since 2005. In Solaris, these Zones are more akin to virtual machines, except much more efficient. All zones shared a single kernel, they just had virtual network interfaces, storage, and could be managed independently. Now, in 2014, Docker brings the same simplicity of Solaris Zones to Linux.

Sure, we've had CGroups in Linux since 2004/2006 but Docker finally brought Linux up to speed with a simple to use capability for creating isolated containers on Linux. Only, the implementation brings with it the same flawed approach as Solaris Zones. Do we really need a full OS image running in a container? I don't think so. Docker images are based on a Linux distro (Ubuntu or CentOS, etc). So we look at this and say, "cool, virtualization without the overhead of interrupts for everything from writing to disk to sending packets over the wire." But is that really the best we can do?

I think what Rocket really represents is a way to do containers right. Containers should run a single process. We shouldn't look at containers as a more efficient VM. We should see containers as a way to increase security and reduce overhead. Do you really want to have to run apt-get or yum inside every container? No. Containers should provide process isolation and application management capabilities. They shouldn't include the OS and the kitchen sink of user land utilities.

This is where Docker has failed. Instead of simplifying administration and deployment, it's introduced its own nuanced approach to system management. The reason we need a Docker competitor (replacement?) is because Docker has failed to live up to its hype.

Do you remember problems something as basic as keyboard?

I certainly have no problems remembering how they recently broke the keyboard in many LG laptops.

Couldn't write a proper wear levelling algorithm if their life depended on it.

First the MAG4FA/KYL00M/VYL00M data corruption bug that affected the Galaxy Nexus - https://android.googlesource.c...

Then (actually BEFORE it, Google found it during Galaxy Nexus development but Samsung kept it hush-hush - but it became a public issue much later) - the infamous Samsung Superbrick fiasco (If you fired a secure erase command at the chip, it had a chance of permanently corrupting the wear leveller data to the point where the chip's onboard controller would crash until you power cycled it any time you accessed that region of flash). - https://git.kernel.org/cgit/li...

Then pre-release 840 PRO devices suffer from the SAME DAMN BUG SAMSUNG HAD BEEN AWARE OF FOR OVER A YEAR - http://www.anandtech.com/show/... - While this only affected review devices, the fact that this was a known bug since before the release of the Galaxy Nexus (a year earlier) is inexcusable.

Then there was the Galaxy S3 "Sudden Death Syndrome" issue in late 2013... - https://github.com/omnirom/and...

Then there were a few other issues - http://wiki.cyanogenmod.org/w/...

Now this...

Even typewriters do it right. Redefining the tab width is like redefining PI to 3 like Linus said.

Nestled with the fact that there are so many git solutions that are third-party hosted only, and so many hostable open source subversion options available

That is because all that you need for GIT is a local directory, SSH, or a Web server. Since your client has a full copy of the repository you can always just fire up gitweb on a local repository.

If you need a GUI to satisfy your needs there is the official web GUI that is distributed with git again no hosting required.
https://git.wiki.kernel.org/in...

If you want more advanced features like Git Hub:
https://about.gitlab.com/ (a near clone of Git Hub)
https://gitorious.org/
and dozens of others (https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools)

I will +1 on the sub-directories deal, but for my use case I just made the sub-directories GIT submodules and everything works itself out. If your sub-directories are really separate parts of a larger project you probably should already have them in separate repositories anyways.

There you go: https://bugzilla.kernel.org/

not even that, it was announced on Phoronix two weeks ago. Slashdot is behind the curve - as usual. Record here shows a commit to the kernel source tree on the 13th August.

Why can't you just look at the preprocessor output?

Go ahead and try it. Get the source code here.

It was less than 2 years ago that the Linux kernel dropped official support for the 80386 chip in the "current" kernel. It's successor, the 80486, has been around since 1989.

Several versions of the Linux kernel that still support the 386 are still officially supported. See http://www.kernel.org/ for details.

No the git comes from the fact that Linus is a git.

Precisely.
"I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."

That's why there is a feature called Write-intent bitmap. There is a performance hit, but it's well worth the rebuild time saved if you value your data.

Never mind trivial things like systemd - the real watershed moment for Old Unix vs New Linux was back in 2011, when a humourless package maintainer excluded 'ddate' from the default build of util-linux:

http://en.wikipedia.org/wiki/D...

https://git.kernel.org/cgit/ut...

https://bugzilla.redhat.com/sh...

The scary thing about Linux is that they can do sometimes platform updates which suddenly break fundamental things like keyboard or ACPI fan control.

But then again, the bleeding-edge development process also allows to get all the new cool features quickly into the kernel.

The scary thing about Linux is that they can do sometimes platform updates which suddenly break fundamental things like keyboard or ACPI fan control.

But then again, the bleeding-edge development process also allows to get all the new cool features quickly into the kernel.

I've been eying this myself, since I would like to upgrade my card to 802.11ac at some point as well. There are two pieces to the puzzle, user space support, and kernel driver support. AFAIK, both are supported but you need fairly new software. The ath10k driver supposedly supports 802.11ac and was included in linux 3.11. I believe newer versions of hostapd support 802.11ac but can't find any specifics about what version it was included in, but the newer the version, the better (so, preferably 2.2). And of course you will need to find a wireless card that uses the ath10k driver. I run my router off a normal PC and have a distro with recent software so this is easy to do, but I have no idea what versions OpenWRT supports.

According to this everything should work: http://wireless.kernel.org/en/...
But according to this there are mixed results: https://forum.openwrt.org/view...

It is abused by creators of malware! All security knowledgeable people know that a microkernel provides micro security --> no security at all !!! :(

Therefore: monolithic kernels!!!! they are most secure!!!

try this kernel here. Its called Linux (Almost). No. Malware. For. Linux.

Linux is worse off now than windows 8 between Unity, GNOME 3 and the cluster fuck that is systemd

I think you must be confused, Linux requires none of the things you just mentioned, and neither does a linux-based OS.

I have always admired RH for it's feature set and pursuit of enterprise-related features.
I do however have one gripe: All the config files are in the wrong place!
This isn't a real complaint, more akin to a whine. I have been using Debian for too many years on far too many servers; my muscle memory demands that the config files that I need to edit be located in the same place across distros.
Does anybody know why there is such a difference in file locations? /etc/network/interfaces
vs /etc/sysconfig/network/networking/where/are/the/damn/config/files

I think the differences are just the normal fragmentation between different distros, with everyone having their own idea of the "correct" place to put the config files. The systemd project is trying to establish a cross distro standard for some of the important config files, making it easier for upstream projects to know where e.g. /etc/os-release is (on non-systemd distros it can be "hidden" almost everywhere).

Systemd is the most important new feature of RHEL 7, since the core of the OS now have been making a huge leap forward in security and reliability regarding processes and deamons. It is now a piece of cake to utilize advanced kernel features like "capabilities" http://man7.org/linux/man-page... and "cgroup" https://www.kernel.org/doc/Doc...

All major distros are about to change to "systemd"; Red Hat, Suse, Ubuntu, Debian. Their derivatives like CentOS, Sci-Linux, Fedora etc. are also changing to systemd, so in a few years, systemd will simply be the new standard toolbox to maintain and run Linux distros, and part of the new future Linux development stack; systemd, Wayland, cgroups and kdbus.

So every Linux System Administrator who have been to procrastinating regarding learning systemd, better start reading up on the subject. A good place to start is : http://www.freedesktop.org/wik...

...and if you want to hear him state his full name and how he pronounces Linux: ftp://kernel.org/pub/linux/ker...

Meanwhile, in Git's crypto code.

(Linked from this blog entry.)

The first link in the article is for The Linux Foundation, who have been publishing the same report since at least 2008, when a minimum of 70% of the contributors (including people who submitted one-line fixes) had corporate sponsorship. Even before then it is easy to see who the top contributors to Linux were -- Kernel maintainer Alan Cox was employed by Red Hat from 1999 to 2009. Ted Ts'o worked with MIT, VA Linux and IBM while he developed /dev/random and the ext2 file system. John "Mad Dog" Hall was the man responsible for making Alpha the second architecture Linux ran on while he worked with Digital. Prior to his employment with Transmeta and the Linux Foundation, Linus Torvalds was paid $20,000,000 in stock options by Red Hat and VA Linux.

Even before the majority of kernel development was done with corporate sponsorship, it was done to further academic goals. While not every one of these people is a dot com millionaire for their work with Linux, calling it a product of slave labour is disingenuous at best.