Slashdot Mirror

KSM efficacy is of course workload dependent; I specifically nodded to this factor as follows:

On a host running many similar guests, extremely large gains in memory deduplication may be seen.

I'm not experiencing issues with memory performance. Could you cite specific data you've collected in your environment? Perhaps huge pages would be helpful for your use case.

Assuming more than a handful of application instances, a container solution is nearly certain to be less prudent. Please feel free to reach out to me via email if you'd like to collaborate on potentially better approaches to the problems you're tackling.

Wikipedia has very detailed information on Intel processors. This page does not list TSX for your processor and does list it for others.

Most Linux distros automatically handle Intel microcode patches (which I assume is how this errata will be handled). See Debian wiki or Arch wiki for details.

Debian will be using the Shuffling Zombie release. So the Shuffling Zombie will live on, for a number of years.

https://lists.debian.org/debia...

You simply don't know the future security bugs that will affect your infrastructure. Just look at http://www.cve.mitre.org/ or any distribution security announcement like https://www.debian.org/securit... . Security bugs are discovered all the time. With this fact in mind you realize that you need more than a single protection layer to get a chance to detect and drop a harmful traffic. The bug could be deep into the kernel, making almost any magic possible from the application point of view. Having only a few ports open is not enough to protect against this, as the kernel structure and notion of port could be corrupted.

No. In fact it's absurdly difficult to reliably create reproducible builds. Debian has been working on this since at least 2009 (afaict) and has been plowing through issues but you still can't get an identical Kernel as the .deb. Heck, it was 8 weeks just for the Tor browser.

It's not just the compilation tools, it's the entire build environment that needs to be homogenized. All kinds of components will insert uname/hostname and paths into the binary, filesystems list the contents of a directory in undefined order, timestamps and permissions are embedded into tarballs and documentation, different locale produces other weirdness.

tl;dr: it's much harder than just installing an identical version of clang and hitting make.

[ And, as an aside, this goes back decades. The infrastructure around builds was never designed with reproducibility as a design goal. We are basically retrofitting this new requirement on decades of legacy code that never even considered that we would want such a thing ... ]

No. In fact it's absurdly difficult to reliably create reproducible builds. Debian has been working on this since at least 2009 (afaict) and has been plowing through issues but you still can't get an identical Kernel as the .deb. Heck, it was 8 weeks just for the Tor browser.

It's not just the compilation tools, it's the entire build environment that needs to be homogenized. All kinds of components will insert uname/hostname and paths into the binary, filesystems list the contents of a directory in undefined order, timestamps and permissions are embedded into tarballs and documentation, different locale produces other weirdness.

tl;dr: it's much harder than just installing an identical version of clang and hitting make.

[ And, as an aside, this goes back decades. The infrastructure around builds was never designed with reproducibility as a design goal. We are basically retrofitting this new requirement on decades of legacy code that never even considered that we would want such a thing ... ]

No. In fact it's absurdly difficult to reliably create reproducible builds. Debian has been working on this since at least 2009 (afaict) and has been plowing through issues but you still can't get an identical Kernel as the .deb. Heck, it was 8 weeks just for the Tor browser.

It's not just the compilation tools, it's the entire build environment that needs to be homogenized. All kinds of components will insert uname/hostname and paths into the binary, filesystems list the contents of a directory in undefined order, timestamps and permissions are embedded into tarballs and documentation, different locale produces other weirdness.

tl;dr: it's much harder than just installing an identical version of clang and hitting make.

[ And, as an aside, this goes back decades. The infrastructure around builds was never designed with reproducibility as a design goal. We are basically retrofitting this new requirement on decades of legacy code that never even considered that we would want such a thing ... ]

Yes, Privacy Badger is a great tool. It's a little tedious when loading content from CDN's, can make pages look pretty bad unless you let a little tracking in... So I also keep my privacy set to delete everything when I close the browser. I also follow the guidelines here ( Scroll down to the Web Browser section ). It's Debian specific but easily translated to whatever mozilla based browsing experience you're using.

As mentioned in the HowTo you can check your "fingerprint" here: https://panopticlick.eff.org/.

And all that said, I have no idea at the moment if any of the above defeats the technique from TFA.

See the chart here: http://automattic.com/work-wit...

Granted there are many people who contribute to the WordPress ecosystem who don't formally work for Automattic given the FOSS nature of WordPress and related plugins. It's just a very different 21st century way of doing business compared to the 20th century Microsoft model, and is doing a better job of bridging the exchange and gift economies (like I talk about on my site).

Automattic, which shepherds the core of WordPress, sounds like a great place to work for people like me who are comfortable working from home. The future for WordPress looks pretty amazing, especially given ever better JSON/AJAX RESTful support for JavaScript-powered frontend apps. See also:
http://inside.envato.com/the-f...
"For those willing to ignore the prevailing opinions in the programming community, Tom Willmot says that WordPress presents developers with incredible opportunities, and a wonderful sense of community: ..."

I've been looking at shifting my own "Pointrel" and "Twirlip" projects, my wife's "Rakontu" and "NarraCat" projects and other similar work (stuff related to participative narrative inquiry, civic sensemaking, public intelligence, social semantic desktop tools, educational simulations, and more) to have JavaScript frontends that use WordPress as an application server backend (rather than have them run stand-alone). That would make it easy for millions of WordPress users who might want such tools to install them as a WordPress plugin with a couple clicks. As Alan Kay said about Squeak, getting people to install anything to try it is hard. Other benefits would include easy authentication support. I expect more and more projects by other people will be moving in that direction. I'm tempted to apply to work at Automattic myself at some point given their FOSS focus. They are also hiring as they got a bunch of venture financing recently. But I would want to make at least a demo of that integration first. I plan on putting such a demo here when it works: http://twirlip.com/

Of course, JavaScript has problems (globals by default), PHP has problems (such a long list..), and WordPress has problems (no doubt), with many problems coming from their historical roots and a need for backward-compatibility. But I can't deny all three won some battle for mindshare for whatever reasons (especially ease of initial use), and when you can't beat 'em, join 'em, right? :-) Like Manuel De Landa wrote in "Meshworks, Hierarchies, and Interfaces", a uniformity on one level can often in turn support a diversity on a level above it.

See also on the value of having a diversity of programmers of a variety of experience levels in an organization:
http://slashdot.org/comments.p...

What I especially envision is that all those millions of WordPress sites could start talking to each other in interesting ways... See also Theodore Sturgeon's 1950s short story "The Skills of Xanadu" for where it all might lead...
http://slashdot.org/comments.p...
https://archive.org/details/pr...

Or as I reprise here:
http://lists.alioth.debian.org...
"Gold Leader: Pardon me for asking, sir, but what good are semantic wikis and desktops going to be against [that]?
General Dodonna: Well, the Empire doesn't consider a small cgi script on a shared server or desktop to be any threat, or they'd have a tighter defense."

Java is, by all benchmarks that I can find, the fastest non-native language that exists. Java was known as slow in 1996. It's been intensely optimized since. I'm sure there are some programs that are sometimes faster due to very circumstantial situations. Here's one example, there are countless others: http://benchmarksgame.alioth.d...

I also think my given citation or the many others I can find just isn't enough to make any declaration about which is "fastest" - it would be safe to say they are fairly equivalent, and this whole argument about their comparative speeds is stupid. Average CPU abilities, amount of memory accessible, and what not change so consistently that anything you write now which is a little bit too slow will be fast enough in a year.

No, it's not.

https://wiki.debian.org/Kernel...

Yup.

Link to the documentation for setting it up and configuring it.

I think my point about the benchmarks is still fair, though: FORTRAN wins (last time I checked) more of the funny language shootout benchmarks than any other single language.

Check again:
Someone contributed better C programs -- programmers matter.
Intel Fortran compared to GCC -- language implementations matter.

Your scheme is very similar to what we use in Debian for voting for the project leader (unlike the fully-open tally sheets for voting on issues, not people). However, this scheme is good only where people trust each other, for ocassions where you know there will be no vote buying/coercion. Not for a national elected government.

Your scheme is very similar to what we use in Debian for voting for the project leader (unlike the fully-open tally sheets for voting on issues, not people). However, this scheme is good only where people trust each other, for ocassions where you know there will be no vote buying/coercion. Not for a national elected government.

Ahhhh, the obligatory FORTRAN circle jerk. A bunch of performance assertions without substance dashed with a healthy ignorance of the value of developer time vs. machine time.

Just a little example though:

50million particle N-body simulation benchmark (http://benchmarksgame.alioth.debian.org/)
Intel Fortran: 20.34s
G++ C++: 20.25s

Oh my gosh, what is that? The sounds of dozens of bearded-old-man-fortran-programmer jaws dropping?

http://benchmarksgame.alioth.d...
http://benchmarksgame.alioth.d...

Ahhhh, the obligatory FORTRAN circle jerk. A bunch of performance assertions without substance dashed with a healthy ignorance of the value of developer time vs. machine time.

Just a little example though:

50million particle N-body simulation benchmark (http://benchmarksgame.alioth.debian.org/)
Intel Fortran: 20.34s
G++ C++: 20.25s

Oh my gosh, what is that? The sounds of dozens of bearded-old-man-fortran-programmer jaws dropping?

http://benchmarksgame.alioth.d...
http://benchmarksgame.alioth.d...

To further belabor the point, Debian's argumentation for systemd shows exactly what is wrong with systemd and how it is a monolithic lump of functionality which does not belong together.

https://wiki.debian.org/Debate...

Quote:
"Systemd is not just init. It unifies, in fewer lines of code, everything that is related to starting services and managing session groups: user login, cron jobs, network services (inetd), virtual TTY management"

Just because scope creep and feature creep leads to fewer lines of code does not make it good engineering. On the contrary, mashing together functionality leads to hard to detect bugs, race conditions and needless complexity and interdependence.

And that is precisely the problem with the monolithic and API based approach of systemd. It becomes fragile and version dependent, which is not what init should be.

Finding "systemctl -xb" you just realise that there actually is something neat about the system being able to understand it's own logs. Finding out that your system is failing to boot because of one directory permission (/var to the wrong user) and that it doesn't start a shell at all or anything you can debug with is just disappointing.

I guess you mean "journalctl -xb". Even so, I had an issue with a mount failing (not a critical one), and systemd dropped me into a what it called a root shell. (See #733232 for a similar situation). Of course, then the system was practically fully up, so the shell was fully functional. However, I refuse to believe that systemd can't start a shell to debug. It might not do so by default, but it can. See http://freedesktop.org/wiki/Software/systemd/Debugging/ (and https://fedoraproject.org/wiki/Systemd_early_debug_shell for what I presume is an older guide).

free to use unless you intend to kill people.

See JSON license. "The Software shall be used for Good, not Evil."

It's probably noteworthy to point out that programs under that license is not accepted in at least Debian.
https://wiki.debian.org/qa.deb...

SNI is universal, unless you're running Windows XP or Android 2.0.3. If you're running either, upgrade. I mean come on, SNI was standardized in 2003 and wasting IPs just for a few legacy clients that ought to have a broken Internet to force them into upgrading is absurd.

Look, its easy. On the https://wiki.debian.org/Freedo... page, theres a link to Learn about Freedombox, which Im sure gives useful information on the project. Heck, that page even links to additional resources here.

Like I said: Easy.

So, you don't know either...

Look, its easy. On the https://wiki.debian.org/Freedo... page, theres a link to Learn about Freedombox, which Im sure gives useful information on the project. Heck, that page even links to additional resources here.

Like I said: Easy.

So, you don't know either...

Look, its easy. On the https://wiki.debian.org/Freedo... page, theres a link to Learn about Freedombox, which Im sure gives useful information on the project. Heck, that page even links to additional resources here.

Like I said: Easy.

So, you don't know either...

The users see the mail client, calendering, and the like, as essential.

Calendaring is one a business task that is critically important to many businesses, but is quite widely ignored in the open source world, at least with respect to easy setup.

In my small office, we use Apple's open source Darwin Calendar Server: http://trac.calendarserver.org... It'll serve calendar data to the mac calendar client, as well as Mozilla's Sunbird client, probably others too.

It works great and it has been extremely stable (I have it running on a debian VM), but it isn't totally trivial to set up. Not hard exactly, but certain OS defaults don't work (e.g., requires extended atrributes, which requires editing fstab, and if you don't, it will never ever work): https://wiki.debian.org/HowTo/...

Anyway, a simple to set up calendar server would be a substantial contribution to the open source business software stable.

Look, its easy. On the https://wiki.debian.org/Freedo... page, theres a link to Learn about Freedombox, which Im sure gives useful information on the project.

A huge bunch of various talks and presentations that are only meaningful to someone who is already familiar with the project? No, that's far from clear and easily-accessible for someone who is not familiar with the stuff, and https://en.wikipedia.org/wiki/FreedomBox seems like the most reasonable available explanation for it. And yet, it's totally not enough.

I still don't really get what they do or what they want, and I really have to say that this kind of approach really doesn't endear random people to the project -- people, that might otherwise start contributing to it. It wouldn't take them much more than a day or two to explain it all on their website and make the project and its developers more approachable, but alas, I get the feeling they want to maintain their own, precious little clique instead.

Look, its easy. On the https://wiki.debian.org/Freedo... page, theres a link to Learn about Freedombox, which Im sure gives useful information on the project.

A huge bunch of various talks and presentations that are only meaningful to someone who is already familiar with the project? No, that's far from clear and easily-accessible for someone who is not familiar with the stuff, and https://en.wikipedia.org/wiki/FreedomBox seems like the most reasonable available explanation for it. And yet, it's totally not enough.

I still don't really get what they do or what they want, and I really have to say that this kind of approach really doesn't endear random people to the project -- people, that might otherwise start contributing to it. It wouldn't take them much more than a day or two to explain it all on their website and make the project and its developers more approachable, but alas, I get the feeling they want to maintain their own, precious little clique instead.

Look, its easy. On the https://wiki.debian.org/Freedo... page, theres a link to Learn about Freedombox, which Im sure gives useful information on the project. Heck, that page even links to additional resources here.

Like I said: Easy.

Look, its easy. On the https://wiki.debian.org/Freedo... page, theres a link to Learn about Freedombox, which Im sure gives useful information on the project. Heck, that page even links to additional resources here.

Like I said: Easy.

Look, its easy. On the https://wiki.debian.org/Freedo... page, theres a link to Learn about Freedombox, which Im sure gives useful information on the project. Heck, that page even links to additional resources here.

Like I said: Easy.

I would like to just point out this is a huge win in my book for Debian.

Are you kidding? Debian once implemented a custom change that deliberately weakened all SSL keys generated on Debian systems:

http://www.debian.org/security...
https://wiki.debian.org/SSLkey...

Young whippersnappers with short-term memory...

I would like to just point out this is a huge win in my book for Debian.

Are you kidding? Debian once implemented a custom change that deliberately weakened all SSL keys generated on Debian systems:

http://www.debian.org/security...
https://wiki.debian.org/SSLkey...

Young whippersnappers with short-term memory...

You shouldn't really put OpenSSH and OpenNTPD in the same sentence... 2k http://qa.debian.org/popcon.ph... vs. 65k http://qa.debian.org/popcon.ph...

You shouldn't really put OpenSSH and OpenNTPD in the same sentence... 2k http://qa.debian.org/popcon.ph... vs. 65k http://qa.debian.org/popcon.ph...

As for Debian / Ubuntu:
The 1.0.1g package is for the testing and unstable versions (Jessie, sid), in Wheezy the bug is fixed in v1.0.1e-2+deb7u5.

Hey jackass, guess what? OpenSSL is in Debian, too. Patched packages for the GnuTLS bug were also released by the Debian security team extremely quickly. Get over yourself.

Please define "as quickly as desired". Debian was fixed on the 3rd of March which is the date of the Debian Security Advisory, that's pretty quick to me. I wonder exactly why this article pops up now, when it's been a long time we've been all patched.

After the Newton School shooting you posted on Slashdot that you would be willing to give up your second amendment right to prevent something like that from happening again. What other rights would you be willing to give up?

Bruce Perens is on record as a notorious hoplophobe.

I lost a lot of the respect I had for him based on his public vitriol in the Newton post on Slashdot. I don't think it's respectable to pick and choose which human rights you support, and the individual right to keep and bear arms is fundamental to the universal right to self-defense.

At least ESR is consistent in supporting liberty in all its forms, in computing and in real life (much to Bruce's obvious chagrin, per the above link).

If it runs as a user (even root), it runs in userspace. It is a privileged user, but that's not actually the same thing.

While not typically done, there is no reason it can't be split into a part that maps the PCI device and a part that requests specific access to those parts.

If you can put up with a performance loss, Xorg CAN be run on top of the framebuffer device as non-root. This ha been doable for years.

Is it the release name?

Yes, it is a release name for the Debian Linux distribution. http://www.debian.org/releases...

With Windows 8 requirement of a license by the proprietary hardware in order to perform a simple Linux install, is wrong. Its real bad. Just say NO to proprietary hardware.

Re-purposing a computer for One Laptop per Child or some other education use is why I buy all my hardware (PC, laptop and tablet) from Linux ONLY vendors. I figure I can always purchase a Windows license if I want one, however down the road that Linux hardware will not require a Windows license to run Linux because of some stupid proprietary chipsets in the hardware.

While there are many Linux only vendors, my favorite is ZaReason. System76 is another one, but they seem to focus on only one or two Linux distros, where the ZaReason techs will put on many more. Loving Debian lately and plan to play with Arch down the road.

Do yourself a favor, avoid any vendor that focuses on Windows and buy Linux hardware and if you really must have the latest version of Windows, purchase a license for your better LINUX hardware. At least it can run Windows without hassles, the converse is no longer true.

A Windows 8 device no longer runs Linux without hassles, best to avoid it for this reason alone.

Apt does feature an unattended-upgrades mode. It's not the default, which is annoying, but it's pretty easy to configure. It's one of the first things I configure on a new Debian box.

As for outdated packages: Debian unstable and experimental usually contain cutting and bleeding-edge versions of most open source software that is packaged in Debian. Unlike the grandparent poster, I would not recommend running sid (AKA unstable) as my main repository, because doing an apt-get upgrade has occasionally wrecked my system on sid. I use Linux Mint Debian Edition, which is based on regular tested snapshots of testing, but I do occasionally need cutting-edge packages. I would recommend looking into apt preferences, which provides a nice way to grab specific cutting-edge packages from unstable and experimental while dragging in a minimal number of unstable dependencies. So far I have had almost no problems doing this, and certainly far fewer problems than using 3rd party repositories.

OpenRC is in Debian: https://packages.debian.org/ex...

And I will upload it to Sid soon.

And by the way, there has never been a declaration that Debian will support *only one* init system. Just that systemd will be the default for Jessie. Nothing more, nothing less. Anyone willing to help the Debian OpenRC team is welcome to do so (by developing OpenRC, testing it in Debian, writing runscripts, etc.).

Iceweasel is a direct port I believe due to the Mozilla binary/branding issue (that Gentoo avoids interestingly enough, with a disclaimer).

Firefox fork in the future?

The entire problem is that it isn't a direct port. Debian sometimes backports security fixes or other bug fixes from newer versions, to fix problems in the version of firefox it decides to support. Doing so violates Mozilla's requirements for using the Firefox artwork and trademark. It wasn't completely ironed out, since they decided to go another way with it, but the gist of it was that a Mozilla rep was suggesting they had to get all fix backport fixes verified by Mozilla first, and if a version of Firefox became obsoleted by Mozilla, Debian would need to change to a new version instead, the same way another distro at the time was doing.

There was originally some back-and-forth about the branding not complying with Debian's free software guidelines, but it all became moot due to the patching issue. The full bug report is here, if you care to skim through.

The good news here is, since they had to give up branding anyway due to their backporting policy, they can remove changes like this if they become detrimental to Debian users or in some way violate DFSG.

They suck at managing daemons, that's what the hell is wrong with them.

Init systems have "worked" for different definitions of work. There are porblems with shell scripts, they lose track of threads easily. They're slow, easy to create circular dependancies.

Take a look at the debian init positions, and see for yourself what they think are major drawbacks of sysvinit. Absolutely *no one* on the tech commitee thinks its a good idea to stay with it. As much animosity as there is between the systemd and upstart camps, no one has listed any other solution besides upstart and systemd as a first or second choice. That should tell you something.

https://wiki.debian.org/Debate...

The presence of the upstart option in this debate and voting was indeed
unfortunate whether it was due to political reasons or technical shortsightedness.
Based on reasonable assessment of technical merits and taking into
account a need for moving forward the competition should have been
between OpenRC and systemd only:

        Debian debate - OpenRC
        Debian debate - systemd

While I admit that right now systemd is more developed and "ready", I
find the design of OpenRC more compatible with the Unix philosophy.

The presence of the upstart option in this debate and voting was indeed
unfortunate whether it was due to political reasons or technical shortsightedness.
Based on reasonable assessment of technical merits and taking into
account a need for moving forward the competition should have been
between OpenRC and systemd only:

        Debian debate - OpenRC
        Debian debate - systemd

While I admit that right now systemd is more developed and "ready", I
find the design of OpenRC more compatible with the Unix philosophy.

You're looking at the upstart position document:

https://wiki.debian.org/Debate... and https://wiki.debian.org/Debate... represent broader parts of the debate.

You're looking at the upstart position document:

https://wiki.debian.org/Debate... and https://wiki.debian.org/Debate... represent broader parts of the debate.