Slashdot Mirror

... resulting from monolithic design problems:
https://linux.slashdot.org/com...
https://www.mail-archive.com/f...
https://slashdot.org/comments....
"Some companies have long considered Smalltalk their "secret weapon" because they could upgrade their systems at least at the application level while the applications continued to run. I guess I've been in computing so long and seen much better innovations like QNX and Smalltalk get passed by in favor stuff like Linux and Java that I guess I don't expect good innovations to be adopted except perhaps decades later. Anyway, I still have a lot of respect for Linus and his accomplishments in bringing a community of people together to do FOSS software. A free Linux is better than an unfree QNX in that sense. Nobody is perfect. And obviously a lot of people here are defending Linus' choice of strong language. Yet, I can't help but feel that the reason Linus is angry, and fearful, and shouting when people try to help maintain the kernel and fix it and change it and grow it is ultimately because Alan Kay is right. As Alan Kay said, you never have to take a baby down for maintenance -- so why do you have to take a Linux system down for maintenance?"

Anyway, nice to see this discussion come up again years later related to a more detailed analysis.

The reason I did not want to use Linux in the first place in the 1990s was because Unix was obviously an out-dated design compared to microkernel-based QNX etc.. But in the end the large community adopted it and so I did too. But I did not have to like the unfortunate core technical choices that traded off things like security, upgradability, understandability, and consistency for a claim to be a bit speedier on certain hardware.

Sort of like Intel's hardware design choices to emphasize speed over security are also now coming home to roost.

If the hit is really 30% for FUCKWIT I wonder if there's a case to be made for a 'I know all the software on my box, don't protect me against kernel to user mode data leakage'.

You could have "--bareback" switch the user could pass into the kernel from the bootloader.

https://www.mail-archive.com/l...

2) Namespace

      Several people including Linus requested to change the KAISER name.

      We came up with a list of technically correct acronyms:

          User Address Space Separation, prefix uass_

          Forcefully Unmap Complete Kernel With Interrupt Trampolines, prefix fuckwit_

      but we are politically correct people so we settled for

        Kernel Page Table Isolation, prefix kpti_

      Linus, your call :)

LOL!

Pretty sure MS-DOS 5.0 was rock-solid enough. It only faltered because things running under it had bugs that overwrote random bits - the kernel itself would be stable.

Here are some known MS-DOS bugs in 5.0 and later (the last one is amusing in its own way):

* DriveSpace (DoubleSpace, a.k.a. what was intended to compete against Stacker) bugs in anything earlier than 6.20: https://en.wikipedia.org/wiki/DriveSpace#Bugs_and_data_loss
* FDISK bugs of several types across several versions: http://www.msfn.org/board/topic/159631-testing-ms-dos-limitations/
* SCANDISK bugs in 6.20 and earlier (Cirrus Logic IDE controllers, when used with VERIFY=ON, resulted in erased drives): http://www.mail-archive.com/survpc@softcon.com/msg01557.html
* INT 21h AH=30h (Get MS-DOS Version function) bug: returns AL=$06 AH=$14 (i.e. 6.20) on 6.21 -- fixed in 6.22 (AL=$06, AH=$16): http://spike.scu.edu.au/~barry/interrupts.html#ah30

Hmm... let's compare some code written by a newbie, with comments that are of no use, with the asm equivalent.

Hmm... let's compare some code written by a newbie, with comments that are of no use, with the asm equivalent.

speaking of opensmtpd...

You might consider these cases as possible examples of being a bit hostile...

http://www.cnet.com/news/debun...
http://www.dailytech.com/Googl...
http://www.zdziarski.com/blog/...
http://www.mail-archive.com/cr...

and to the lesser extent where Linus posts stuff like ...

one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior. It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important.

or

I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them.

https://www.youtube.com/watch?... "Acclaimed journalist, author and political activist Barbara Ehrenreich explores the darker side of positive thinking."

I've written before on how the monolithic Linux kernel design may be significantly increasing Linus' stress as a kernel manager (as the Kernel moves closer to some point of collapse or major security breach from complexity -- of which the systemd controversy is a big symptom).
https://www.mail-archive.com/f...

But I don't see everyone migrating to Minix 3... :-) Or something else.

Tanenbaum's early choice of proprietary license for Minix will go down in history of one of the biggest licensing mistakes of all time -- even if it is free now, and recently had millions of euros of public funds poured into it.
http://en.wikipedia.org/wiki/A...
http://www.minix3.org/

But had we all moved to Minix, we would probably not be hearing that much swearing by Andrew Tanenbaum or other Minix kernel maintainers compared to Linus Torvalds and other Linux kernel maintainers, as with so few core lines, there is not much to maintain in the Minix kernel, and so it is easier to test and debug. See:
http://wiki.minix3.org/doku.ph...
"Monolithic operating systems (e.g., Windows, Linux, BSD) have millions of lines of kernel code. There is no way so much code can ever be made correct. In contrast, MINIX 3 has about 4000 lines of executable kernel code. We believe this code can eventually be made fairly close to bug free."

I feel ultimately that difference is why Linus Torvalds is stressed enough that he spouts so much profanity at kernel maintainers when they make a mistake -- a fact he may never be able to admit? :-)

Anyway, some of this is cultural. By contrast to the USA, people in, say, the Netherlands are more forthright and less quick to take offense (another cultural aspect). In the USA, you never know how quickly your cutting comment might make an enemy (including, say, the above). Anyway Linus, I may disagree on monolithic vs. micro kernel design obviously, but kudos to you for going free early and often!!! And git is great! :-)

Cool; don't recall trying that back then!

BTW, on your user name (LinuxIsGarbage), I resisted using Linux for years, because I knew better things were possible (like QNX and its microkernel for internals, or any software a more systematic approach to naming commands and command options as far as command line utilities). Ultimately though, those two factors will likely lead to its replacement -- although perhaps the result will still be called "Linux", just with a very different shell and a very different kernel. :-)

I feel one reason Linus Torvalds has gotten, and needed to get, such a reputation for profanity and being an effective gatekeeper hardass for software quality is because of a fundamental weaknesses in monolithic kernel design relative to a dynamic community with a variety of ever changing needs. I've written before on that is a couple Slashdot comments, such as in a story about the last time he chewed out a kernel developer bigtime.
https://www.mail-archive.com/f...
http://slashdot.org/comments.p...

I had hoped for something much better -- even perhaps something modular based on Forth or Smalltalk/Squeak! But for whatever reason Linux got the social momentum behind it, so I started using it too hoping it would improve over time (and it has). I started trying it around 2000 or so as toe dipping, and then used it as my main desktop (Debian) around 2003 or so until ditching it for OS X as a desktop around 2008 or so (getting tired of so much breakage with every upgrade, plus wanting some Mac-specific scanner OCR software). I still use Linux for servers and such, but my main web server (maintained by someone else) is a BSD variant, which I consider somewhat more secure/reliable. I'm thinking about going back to Linux given Apple's dropoff in quality with later OS upgrades (I'm still lagging a few versions, but know that can't last without patches etc..).

But as with the theme of the original article, the fact that QNX, Forth, or Smalltalk (or others, Symbolics Lisp Machine?) was there first in some key ways as far as making for good interactive experiences has apparently been mostly forgotten.

"What kind of people are these that use vulgar, profane language in these posts. Personally, such people's critiques should be ignored and consigned to the local sewage inlet. A very sad comment on contemporary society."

Just as a guess, putting any person-to-person (mis)communication or personality aspects aside, I think a lot of programmers are frustrated with the state-of-the-art in programming. Examples include the proliferation of JavaScript despite its needlessly confusing warts and missing pieces (same and worse for PHP), Java not fulfilling its promise of ease of installation with lots of versions despite stealing Smalltalk's thunder and having vast amounts of money poured into it, C++ being so confusing and easy to shoot yourself in the foot with, a huge proliferation of half-finished languages, Python and Perl splitting with major new not-backwardly-compatible versions, version, a proliferation of mostly similar FOSS licenses and yet incompatibly-licensed code you can't legally use or distribute together, too many buggy libraries that do almost the same thing and much of what you want but have somewhat different bugs, entrenched awkward "scripting" languages with low performance and are not really much easier to use than other languages for anything substantial or that needs to be maintained or debugged, lack of good documentation for so many projects, badly written software that is hard to understand yet does useful things, lack of tests, vast amounts of computing power in hardware but seeing it frittered away or not being able to easily access it or it being wasted on supporting huge amounts of duplicated inefficient code including likely several different interpreters, library dependency hell, bit rot including of FOSS contributions getting left behind, layer upon layer of abstraction ignoring more abstraction can't solve the issue of too much abstraction, confusing conflict-of-interest marketing information to sort through, data encoded in proprietary or unusual formats and so hard to use, a proliferation of confusing or intentionally limited "standards", the frequent ignorance of the history of programming among programmers who have not lived it, and so on.

For anyone who has programmed for decades and seen what it felt like to use Forth, Smalltalk, BASIC on a C64, or even an assembly language monitor, there is some huge mismatch these days between what we *feel* should be possible and the systems we are in practice forced to work with these days either for economic reasons or reasons of trying to get incremental changes adopted. Notice I said "feel should be possible", so it is a feeling or aspiration -- whether it is reasonable expectation is another issue.

That frustration may express itself as profanity when a programmer see resources (including just getting a Slashdot discussion going) going to new projects that don't seem to really address or acknowledge these fundamental issues. Worse, new projects that don't recognize these issues may just be adding further to all the confusion and complexity (yet another syntax to learn and guess at for ambiguities, yet another lack of documentation, yet another maybe great library that is effectively unusable because of the complex interdependencies or choices about context like desktop vs. web, etc.).

Contrast with Alan Kay's Fundamentals of New Computing (FONC) project which at least acknowledges some of these issues even if it may not fully deliver on all or even many of them (and I have my own criticisms on stuff FONC has ignored).
https://mail.python.org/piperm...
https://www.mail-archive.com/f...

I 've suggested it's possible Linus Torvald's profanity also has some of the same roots of frustration at overwhelming complexity and harder-to-manage risks because of it:
"[fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot"

And USB does need to be in the kernel for performance reasons when you're dealing with USB3 and devices like hard drives.

That is a common misconception, which has, in my opinion, lead to a lot of bad designs from the security perspective. Genode has USB3 support, and it does not do any drivers at all in the kernel (That is a USB driver from linux running outside of kernel space providing usb 3.0 support btw). They also support hard drives, and none of that support is in the kernel. There is a bit more discussion on the topic on their mailing list addressing performance of micro kernels in general which inherently have all such drivers outside of the kernel. You need a good design to make it work, but there is strong evidence it can be done (we have working examples). I recommend reading into the Genode project. Its really quite interesting (and impressive) from a security perspective, as well as a general system design one. They are tacking a nice purist approach to security focused on minimizing the trusted set.

From: http://vpri.org/fonc_wiki/inde...
---
We are faced with a need for significant action and the odds are stacked against us. Invention receives no attention, and innovation (even when incorrectly understood) receives lip service in the press but no current-day vehicle exists to to nurture it. This wiki is an open invitation for talented individuals to pool their energy and collaborate towards fundamentally changing computing.

Over the years many groups have debated how to make progress in computing. There were likely as many opinions as there were people in the debates. Nevertheless personal accounts suggest that initiatives were sometimes reduced to a handful and then pursued with vigour. Consider what could be achieved by following the same pattern today, with the added benefit of doing it as a virtual, distributed team.

Our goal could be to capture the significant ideas and initiatives that we have been exposed to, are aware of, or can discover, distil them into groups, reduce them to a handful of concepts worthy of vigorous exploration, and focus our efforts on these common ideas with the eventual aim of making substantial progress towards finding a common set of fundamentals of new computing.
---

See also: http://vpri.org/fonc_wiki/inde...

A big focus of FONC was in reducing lots of complexity. Smalltalk shows what is possible... But in practice new languages and new standards often just add more complexity to the mix and what we often need are better tools for dealing with complexity. And community and trends mean a lot too, as does hireability and ubiquity and easy installability. So, again, in practice, I'm moving to JavaScript with conceptually simple backends (even in, yikes, PHP) -- inspired in part by Dan Ingall's own work with the Lively Kernel which shows what is possible as near-zero-effort-to-install JavaScript apps.

My own thoughts on FONC from 2010:
"fonc] On inventing the computing microscope/telescope for the dynamic semantic web"
https://www.mail-archive.com/f...
---
Biology made a lot of progress by inventing the microscope -- and that was done way before it invented genetic engineering, and even before it understood there were bacteria around. :-)

What are our computing microscopes now? What are our computing telescopes? Are debuggers crude computing microscopes? Are class hierarchy browsers and package managers and IDEs and web browsers crude computing telescopes?

Maybe we need to reinvent the computing microscope and computing telescope to help in trying to engineer better digital organisms via FONC? :-) Maybe it is more important to do it first? ...

It's taken a while for me to see this, but, with JavaScript, essentially each web page can be seen like a Smalltalk ObjectMemory (or text-based image like PataPata writes out). While I work towards using the Pointrel System to add triples in a declarative way, in practice, the web of calling cgi scripts at URLs is a lot like message passing (just more like the earlier Smalltalk-72 way without well-defined syntax). So, essentially, a web of HTML pages with JavaScript and CGI on servers is like the Smalltalk system written large. :-) Just in a very ad hoc and inelegant way. :-)

---

The original idea was millions of end users running Bitcoin mining as a background job on their CPU. That's totally dead.

The author of the original idea bets to disagree:

Long before the network gets anywhere near as large as that, it would be safe
for users to use Simplified Payment Verification (section 8) to check for
double spending, which only requires having the chain of block headers, or
about 12KB per day. Only people trying to create new coins would need to run
network nodes. At first, most users would run network nodes, but as the
network grows beyond a certain point, it would be left more and more to
specialists with server farms of specialized hardware. A server farm would
only need to have one node on the network and the rest of the LAN connects with
that one node.

That is from Satoshi Nakamoto's post from 2008: http://www.mail-archive.com/cr...

This is actually the OpenBSD developers diving in because the upstream (OpenSSL) was unresponsive. If you look at the actual commits, you will see removal of dead code such as VMS-specific hacks

That code is not dead, there are actually still people using OpenSSL on OpenVMS and actively providing patches for it: https://www.mail-archive.com/o...

Regarding binary and source code distribution, there's nothing to fix really - both source and binaries are already protected by X.509 certificates by virtue of being hosted on SSL-using websites: https://www.mail-archive.com/b...

This in no way prevents the server from being compromised and serving a malicious installer package. It prevents a MitM attack from compromising the package in transit, but that's it.
Code signing and SSL are protections against completely different attacks, and are not interchangeable.

Regarding binary and source code distribution, there's nothing to fix really - both source and binaries are already protected by X.509 certificates by virtue of being hosted on SSL-using websites: https://www.mail-archive.com/b... Secondly PGP keys are hosted on https://bitcoin.org/ which gives users a manual way to get them securely, verified by X.509. We should check that certificate pinning is being used, and it'd be good to have a second code repo beyond github, but we're in pretty good shape already. I'm willing to call a spade a spade: Mike's loud pronouncement about how this is proof that PGP sucks is trolling.

As for payment authentication, keep in mind I'm a consultant. I act as official Chief Scientist for Mastercoin, and unofficial "chief scientist" for a whole bunch of other projects. My job is to advise other people who are doing the actual work; if I tried to fix everything directly myself I'd be wasting my time. Heck, right now I'm writing an (private) email outlining some ideas on the specifics of OpenPGP/X.509 integration to one of my clients and I expect we'll start to see this stuff get actually implemented in the future. It won't be my code, but I'm happy to have done my part in guiding others building secure systems.

Bitcoin already uses X.509 to sign code and binaries anyway because they're both hosted on SSL-secured websites: https://www.mail-archive.com/b...

So why is Mike Hearn trying to remove a verification method in favor of relying only on obviously more risky SSL? Now that we know the NSA is actively trying to subvert cryptography usage and standards, anyone arguing to make things weaker should be treated with suspicion.

The code on-screen was real code from SQLite. The line that contained the memory leak was added by the producers. More information here: http://www.mail-archive.com/sq...

Or maybe it is the card owner's responsibility.

The real problem is everyone has been coming up with "Go buttons" but there was no decent "Stop button". So to stop some stuff but not others you have to make sure ALL the unwanted Go buttons" are not pressed. And that is not easy to do. Some people say "Use a library" the problem is how do you make sure future "Go buttons" that haven't been invented yet are not pressed either? And how about different browsers behaving differently?

So more than 10 years ago I proposed that a "Stop" "button" be created: http://lists.w3.org/Archives/Public/www-html/2002May/0021.html
http://www.mail-archive.com/mozilla-security@mozilla.org/msg01448.html

But there was no interest in such a thing till recent years with CSP: https://developer.mozilla.org/en/docs/Security/CSP

If the major browsers had implemented my simple suggestion years ago it would have been harder for the Yahoo, MySpace and other worms.

They've apparently been interfering with open source and free software. (See John Gilmore's notes about the security agency hindered deveopment of IPsec, at http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html )

both socially and technically? By me: http://www.mail-archive.com/fonc@vpri.org/msg03714.html
"After citing Alan Kay's OOPSLA 1997 "The Computer Revolution Has Not Happened Yet" speech, the key point I made there is: "Yet, I can't help but feel that the reason Linus is angry, and fearful, and shouting when people try to help maintain the kernel and fix it and change it and grow it is ultimately because Alan Kay is right. As Alan Kay said, you never have to take a baby down for maintenance -- so why do you have to take a Linux system down for maintenance?" ... So, perhaps now we finally twenty-years see the shouting begin as the monolithic Linux kernel reaches its limits as a community process? :-) Still, even if true, it was a good run."

That was about this slashdot post of mine, which included:
http://slashdot.org/comments.pl?sid=3346421&cid=42430475
"Again, whether using a 2X4 to get someone's attention was appropriate or not in this case, the deeper issue may also be that the strong emotions expressed by Linus may reflect a fundamental problematical issue in the Linux kernel architecture and development processes. Why does Linus have to be so afraid of so many continually needed patches breaking the system in a hard-to-understand and test way? At some point, it may be reasonable to say that what *most* users need is not a 20% or whatever performance improvement by a monolithic kernel but instead maybe what they would be better off with is a microkernel that supports easier upgrades, improved reliability, easier portability, and thus helps software developers to do new things with less effort and higher quality. And as QNX demonstrated in the 1980s, being able to do easy parallel processing across a network of thousands or millions of processors exchanging messages may be ultimately a much bigger performance boost than, say, a few percent greater performance on one processor. That is the promise of "message passing" whether implemented in a microkernel or not."

I'll link you to what he said. (I'm not sure if you haven't read this particular bit, or if you have and are just trying to make a case for some magical ponies-and-rainbows world.)

I submit that what he said there provides more useful criticism than your suggestion, despite the usage of... well, really not very much profanity at all. (Tallying up everything that could even vaguely be considered "bad language", I get three "crap"s, two "shit"s, one "hell", and one "WTF".)

In addition, your response is more punitive than is probably necessary, considering that the person in question has a history of committing good code normally. You'd seriously operate on a two-strikes policy for bad commits?

I don't think you quite grasp the scale of "expensive" in this case.

Even with modern processes it can still come to hundreds of dollars per line to actually be certain.

http://www.mail-archive.com/sc-l@securecoding.org/msg01278.html

Though that only covers making sure it does what you think it should do, it doesn't cover making sure what you think it should be doing is what the client thought they were telling you it should be doing.

What you actually want is code which *probably*
  has very few bugs which you can create for a sane price and at a sensible speed because most clients want their software this year, not 10 years from now.

There's always a tradeoff.

https://bugs.webkit.org/show_bug.cgi?id=79680#c3
http://kalev.fedorapeople.org/midori_about_widgets.png

http://www.mail-archive.com/webkit-gtk@lists.webkit.org/msg01200.html

And webkitgtk is at 1.10.2 now, but this particular bug is still not fixed.

Yes - you can "fix" this by compiling webkitgtk against gtk3, but then the audio and video tags are messed up. They are transparent and have no slider.

Still suspect this could have something to do with the SSL backdoor allegations made a while back. http://www.mail-archive.com/full-disclosure@lists.grok.org.uk/msg47029.html

Yes I know the allegations have largely just petered out over time, but this doesn't allay my suspicion.

I suggested something like that 10 years ago: http://lists.w3.org/Archives/Public/www-html/2002May/0021.html
http://www.mail-archive.com/mozilla-security@mozilla.org/msg01448.html
But hardly anyone was interested. If implemented it could have prevented the Hotmail, MySpace, yahoo and many other XSS worms.

There's Content Security Policy now:
https://developer.mozilla.org/en-US/docs/Security/CSP/Introducing_Content_Security_Policy

As far as I see security is not a priority for the browser and W3C bunch.

Unfortunately, not all the users are reasonable and well behaved. There were a few addresses that were hitting me with a query per second. And you can't blacklist these anti-social idiots because if you do, they're still consuming inbound bandwidth.

I feel your pain, and it is (or at least was) made worse by ntpd itself. I tried to get limiting working a few years ago, but in the end my server kept answering requests from even the most abusive clients. This peeved me greatly. When I've flagged a client as bad, stop talking to them.

I still wanted to help out with the pool, though. I ended up adding a few dummynet pipes with random delays from 0 to 30 seconds and various probabilities of being used, and maintained a manual blacklist of abusive clients who got their answers redirected back through those randomly delayed pipes. That actually seemed to work; those clients noticed that my clock was between 0 and 30 seconds off at any given time and eventually stopped asking.

I don't recommend that approach as it was fairly labor intensive, but I did enjoy my BOFH moment in the sun.

I'm not going to do the homework for you

Actually it is your responsibility to provide something more than bold claims when it comes to supposed security vulnerabilities.

I can only find one claim from Adam Borowski <kilobyte@angband.pl> that "lxc is not supposed to be secure (it provides a chroot with usage limits, but no isolation)", what is incorrect despite being unchallenged in that particular thread.

I don't have the blog entry handy, but I for sure tested it myself

"The blog entry" was extensively discussed in this thread: http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg02368.html , and it was demonstrated that it's possible to use existing and widely used mechanisms in Linux kernel to prevent attacks of this kind, most relevant messages being http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg02382.html and http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg02375.html .

The link to the python script mentioned, no longer works due to what looks like switch to Git, so it's now http://git.coredumb.net/cgit.cgi/coredumb/tree/scripts/python/smack_label.py .

While those mechanisms may sound complex, may happen to be buggy, and are surrounded by all kinds of disclaimers, same applies in spades to virtualization implementation and virtual environment management tools. Just because VMWare is run by overconfident assholes who refuse to acknowledge impact of their products' bugs, does not mean that virtualization is not supposed be taken with the same expectations.

So far, it looks like a trivial combination of well-known mechanisms present in Linux kernel, provides a securely isolated environment within LXC right now, despite all the claims that LXC is "doing it wrong" by not bundling a namespace mechanisms with it, or various trash-talk from fans of virtualization and other host compartmentalization methods.

It would be a valid criticism toward OpenStacks, distributions and other LXC users if those people were neglecting to provide secure configuration and documentation on it as it applies to the security models and policies of their application. But this is not what you claimed, you claimed that the whole mechanism is insecure and therefore unusable, and you have nothing to back your statements but dismissive remarks of unrelated people and exploits for blatantly insecure configurations that happen to use LXC.

So back to your own irresponsible behavior:

If LXC implementation is fundamentally insecure as you claim, it's supposed to be treated as broken, and it should not be available in any "stable" version of anything. If that was the case, either:

1. There would have to be an easily accessible announcement (at very least, a CVE entry).
or
2. Security practices of Linux kernel developers, OpenStack developers and all distributions are unsafe.

Referring to some mythical mailing list messages about other products and features without such reference amounts to FUD-mongering on par with our Microsoft-sponsored friends. This is completely unrelated to your own lack of research on the subject -- ignorance and laziness by themselves are forgivable, spewing vague ignorant bullshit is not.

I'm not going to do the homework for you

Actually it is your responsibility to provide something more than bold claims when it comes to supposed security vulnerabilities.

I can only find one claim from Adam Borowski <kilobyte@angband.pl> that "lxc is not supposed to be secure (it provides a chroot with usage limits, but no isolation)", what is incorrect despite being unchallenged in that particular thread.

I don't have the blog entry handy, but I for sure tested it myself

"The blog entry" was extensively discussed in this thread: http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg02368.html , and it was demonstrated that it's possible to use existing and widely used mechanisms in Linux kernel to prevent attacks of this kind, most relevant messages being http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg02382.html and http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg02375.html .

The link to the python script mentioned, no longer works due to what looks like switch to Git, so it's now http://git.coredumb.net/cgit.cgi/coredumb/tree/scripts/python/smack_label.py .

While those mechanisms may sound complex, may happen to be buggy, and are surrounded by all kinds of disclaimers, same applies in spades to virtualization implementation and virtual environment management tools. Just because VMWare is run by overconfident assholes who refuse to acknowledge impact of their products' bugs, does not mean that virtualization is not supposed be taken with the same expectations.

So far, it looks like a trivial combination of well-known mechanisms present in Linux kernel, provides a securely isolated environment within LXC right now, despite all the claims that LXC is "doing it wrong" by not bundling a namespace mechanisms with it, or various trash-talk from fans of virtualization and other host compartmentalization methods.

It would be a valid criticism toward OpenStacks, distributions and other LXC users if those people were neglecting to provide secure configuration and documentation on it as it applies to the security models and policies of their application. But this is not what you claimed, you claimed that the whole mechanism is insecure and therefore unusable, and you have nothing to back your statements but dismissive remarks of unrelated people and exploits for blatantly insecure configurations that happen to use LXC.

So back to your own irresponsible behavior:

If LXC implementation is fundamentally insecure as you claim, it's supposed to be treated as broken, and it should not be available in any "stable" version of anything. If that was the case, either:

1. There would have to be an easily accessible announcement (at very least, a CVE entry).
or
2. Security practices of Linux kernel developers, OpenStack developers and all distributions are unsafe.

Referring to some mythical mailing list messages about other products and features without such reference amounts to FUD-mongering on par with our Microsoft-sponsored friends. This is completely unrelated to your own lack of research on the subject -- ignorance and laziness by themselves are forgivable, spewing vague ignorant bullshit is not.

I'm not going to do the homework for you

Actually it is your responsibility to provide something more than bold claims when it comes to supposed security vulnerabilities.

I can only find one claim from Adam Borowski <kilobyte@angband.pl> that "lxc is not supposed to be secure (it provides a chroot with usage limits, but no isolation)", what is incorrect despite being unchallenged in that particular thread.

I don't have the blog entry handy, but I for sure tested it myself

"The blog entry" was extensively discussed in this thread: http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg02368.html , and it was demonstrated that it's possible to use existing and widely used mechanisms in Linux kernel to prevent attacks of this kind, most relevant messages being http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg02382.html and http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg02375.html .

The link to the python script mentioned, no longer works due to what looks like switch to Git, so it's now http://git.coredumb.net/cgit.cgi/coredumb/tree/scripts/python/smack_label.py .

While those mechanisms may sound complex, may happen to be buggy, and are surrounded by all kinds of disclaimers, same applies in spades to virtualization implementation and virtual environment management tools. Just because VMWare is run by overconfident assholes who refuse to acknowledge impact of their products' bugs, does not mean that virtualization is not supposed be taken with the same expectations.

So far, it looks like a trivial combination of well-known mechanisms present in Linux kernel, provides a securely isolated environment within LXC right now, despite all the claims that LXC is "doing it wrong" by not bundling a namespace mechanisms with it, or various trash-talk from fans of virtualization and other host compartmentalization methods.

It would be a valid criticism toward OpenStacks, distributions and other LXC users if those people were neglecting to provide secure configuration and documentation on it as it applies to the security models and policies of their application. But this is not what you claimed, you claimed that the whole mechanism is insecure and therefore unusable, and you have nothing to back your statements but dismissive remarks of unrelated people and exploits for blatantly insecure configurations that happen to use LXC.

So back to your own irresponsible behavior:

If LXC implementation is fundamentally insecure as you claim, it's supposed to be treated as broken, and it should not be available in any "stable" version of anything. If that was the case, either:

1. There would have to be an easily accessible announcement (at very least, a CVE entry).
or
2. Security practices of Linux kernel developers, OpenStack developers and all distributions are unsafe.

Referring to some mythical mailing list messages about other products and features without such reference amounts to FUD-mongering on par with our Microsoft-sponsored friends. This is completely unrelated to your own lack of research on the subject -- ignorance and laziness by themselves are forgivable, spewing vague ignorant bullshit is not.

The truth about KDE: http://www.mail-archive.com/misc@openbsd.org/msg88679.html I also remember them coming to misc and inform the community and porters that KDE won't run on openbsd due to the use of a cool linux daemon to manage stuff.

This was said to be true about GNOME3, where it was rumored that one linux daemon systemd was required - but OBSD seems to support GNOME3 in fallback mode. The fallback mode support for GNOME3 seems to be due to the requirement that in GNOME3, the GNOME shell requires 3D accelaration to work, as it requires graphics composition. That brings into focus the fact that most graphics cards don't include open source drivers, and while that's not a roadblock for FBSD, it does seem to be more of one for OBSD. On the FSF side of things, some of the FSF endorsed Linux distros, like Trisquel, had the same issue, and they too defaulted w/ this fallback mode GNOME option.

Was this ever a problem in KDE4? While KDE4 had initial problems due to Qt4 being unready at the time, KDE4.8, as it stands today, is reasonably mature. KDE5 and beyond will support Wayland in addition to X, but OBSD needn't go that route if it doesn't want to. At any rate, does KDE4.8, like GNOME3, require 3D accelaration to get going? I've never heard of KDE having such a requirement.

They don't include Emacs (instead mg is in base, rewritten from scratch with a funny easter egg inside) neither do they include Libre Office. It's just a Makefile and some patches that are distributed. Package are a convenience for the users, and available only if the license is 'free' enough (i.e legally possible). They want to switch to pcc instead of gcc, I've heard that Theo does that.

Okay, why does this page seem to suggest that Emacs and Libre Office are included? Very strange!

OpenBSD's IPv6 stack is one of the most mature stack. I bet its code is already somewhere else (free license => not wasting engineering efforts). You might want to read about Packet Filter if your especially interested in tunning/handling IPv6 traffic.

Apache is actually an old version of apache, before the license sucked, and it underwent a lot of changes. Don't compare it to nginx. You can get it in the ports/package sysem if your not happy with the shipped apache.

I listed my questions about IPv6 support above, under the discussion I renamed 'IPv6 support'.

As a side note, OpenBSD uses the ISC license when i can now. Might be worth looking ;).

It doesn't use the normal BSD license like other BSDs?

The truth about KDE: http://www.mail-archive.com/misc@openbsd.org/msg88679.html
I also remember them coming to misc and inform the community and porters that KDE won't run on openbsd due to the use of a cool linux daemon to manage stuff.

They don't include Emacs (instead mg is in base, rewritten from scratch with a funny easter egg inside) neither do they include Libre Office. It's just a Makefile and some patches that are distributed. Package are a convenience for the users, and available only if the license is 'free' enough (i.e legally possible). They want to switch to pcc instead of gcc, I've heard that Theo does that.

OpenBSD's IPv6 stack is one of the most mature stack. I bet its code is already somewhere else (free license => not wasting engineering efforts). You might want to read about Packet Filter if your especially interested in tunning/handling IPv6 traffic.

Apache is actually an old version of apache, before the license sucked, and it underwent a lot of changes. Don't compare it to nginx. You can get it in the ports/package sysem if your not happy with the shipped apache.

As a side note, OpenBSD uses the ISC license when i can now. Might be worth looking ;).

...
if (paramHashValues.containsKey(key)) {
values = paramHashValues.get(key);
} else {
values = new ArrayList(1);
paramHashValues.put(key, values);
}
values.ensureCapacity(values.size() + newValues.length);
for (String newValue : newValues) {
values.add(newValue);
}

which means that if a hash-collision is detected the values are added to the valueset (instead of modifying the hash algorithm).

Just compare the release histories

Cent OS has a lag of anywhere from around a month, to 9 months in the case of 6.0, and 5 months and counting for 6.1. I have no idea of the delay for bug fixes, particularly security bugs, but I wouldn't be surprised if there was a decent delay there as well.

For the support angle, it's not so much the case that you're going to call them up and ask how to configure apache. But if you do encounter a bug that a real issue they're going to take it a lot more seriously if you're paying them some money.

Also note that 3rd party packages are generally packaged for RHEL, I recently tried to set up a Cent OS virtual server for my own use and ended up switching to Fedora since the LDAP package I wanted couldn't be installed on Cent OS. And that's not just the first example, I remember a previous co-worker who convinced his manager to get RHEL after screwing around with another 3rd party app that didn't like Cent OS.

Cent OS is great for some uses, but it can also be an extra hassle, and if you've got the cash to avoid the potential complications I'd go for it.

3) This guy was banned for only a month because he was responding in a very hostile way. He was told he would be unbanned at that point. However, he seems just like an angry individual in general, and I hope he gets counseling or something in order to help with anger management issues. He was not banned because he forked Growl, I think that's kind of neat actually and the point of being open source. He was being a poisonous person, and was removed as such. I will not discuss this any further, but wanted to address this here.

I'm sure you have no desire to discuss it any further, since it would shed a very unfavorable light on you. Still, I'd like you to point me to one (only one) angry/hostile post by this user. Because to me you seem to be the angry one, see http://www.mail-archive.com/growldiscuss@googlegroups.com/msg09608.html

http://www.mail-archive.com/cybershooters@compuserve.com/msg03372.html
Back in 2001 the US was thinking about it: "... will find repeated exposure to violent entertainment during early childhood causes more aggressive behavior throughout a child's life, according to a draft of the report obtained by The Times."

"... such as by making the code into it's own executable and shelling out to it ..."

Which is what they did when they used ffmpeg & mencoder in one of their other products, Hamster Free Video Converter.

In other words, they have a history of this type of thing...

I am specifically referring to names in the kernel source tree using conflicting cases such as:

include/linux/netfilter/xt_connmark.h
include/linux/netfilter/xt_CONNMARK.h

This requires that the kernel source be stored on a case insensitive file system, and will not work with Cygwin, nor with the default filesystem for OS X.

I don't think building under Cygwin or OSX is a high priority to the Linux kernel developers :) That being said, why should Linux kernel sources be forced to support building from antiquated filesystems? Also, I can understand Windows having this problem, but OSX? I thought they would have at least got that right. Wow. Add another item to the long list of reasons to avoid OSX.

And from that link you provided:

When I tried to checkin the Kernel tree into Perforce,

Really? Seriously? I'm surprised anyone is even using Perforce.

Tell you what, why don't you do us a favor and file bug reports with Microsoft and Apple and tell them to try dragging their asses into (at least) the 20th century; UNIX has had case sensitive filesystems forever, so there's really no excuse. Hell, git works fine with mixed case on vfat under Linux. If case sensitivity is (supposedly) a user problem, well a) people mucking about with kernel sources should know better, and b) it should be solved in the DE/GUI/file manager (ie, application) level, not the kernel level.

That's all ready there.

[citation needed]

I am specifically referring to names in the kernel source tree using conflicting cases such as:

include/linux/netfilter/xt_connmark.h
include/linux/netfilter/xt_CONNMARK.h

This requires that the kernel source be stored on a case insensitive file system, and will not work with Cygwin, nor with the default filesystem for OS X.

Examples:
Local uncommitted changes, not checked in to index with gitk
Kernel 2.6.20 File Names Case Sensitivity
The Linux kernel needs a case sensitive filesystem
Another LFS newb is stuck: Linux API headers won't install

etc.

A quick Google search only turns up one serious discussion about the possibility of a ThumbEE - oriented Dalvik. The only reply wasn't very optimistic about it, saying that a 16-cycle mode switch between ThumbEE and regular instructions makes it unlikely to be worth it.

More's the pity- I really think VM guys and processor design folks need to get their heads together.

Not all of them. Just #1.
http://www.icjt.org/npp/podrobnosti.php?drzava=14&lokacija=818

They are all pretty old anyway ( but have allegedly been used for interesting stuff before: http://www.mail-archive.com/envorum@ypb.or.id/msg00425.html )

What I'm wondering about is China. China gets big earthquakes too and they're building dozens of reactors. Many with the AP1000 design that some people don't think is safe enough: http://en.wikipedia.org/wiki/AP1000#Safety_concerns

I actually made the feature request to KDE years ago: http://bugs.kde.org/show_bug.cgi?id=121349

And more recently to GNOME too:
http://www.mail-archive.com/usability@gnome.org/msg04993.html

Since nobody in KDE/GNOME was interested in implementing it, I wrote LinkKey (for Windows since I prefer Windows for desktop stuff to KDE/GNOME. FWIW, my home server is running a Linux distro, so I am far from anti-Linux or OSS).

I might revisit Desktop Linux if Windows gets worse. But KDE and GNOME are currently worse and GNOME sure looks like it won't be good for me any time soon.

Jesus FUCKING Christ!
Quit saying that!
While GPS *could* use dopler shift, most do NOT! You can't make a blanket statement that they all do. It is utter bullshit.

I emailed garmin on this question:

Dear xxxxx,

Thank you for contacting Garmin International. I'd be happy to help you with your Legend.
The unit determines speed by using the track log data and calculating time/distance between those points.
Please let me know if there's anything else I can assist you with.

With Best Regards,
Debbie B
Product Support Specialist
Outdoor/Fitness Team
Garmin International

Here is something from google groups on the issue:
http://www.mail-archive.com/android-developers@googlegroups.com/msg57902.html

It is pretty easy to show that consumer GPSR's aren't that accurate, speed-wise. I can easily break the speed limit and slow back down with my Android or eTrex being none the wiser.

So please, next time this discussion comes up, remember this conversation? It is like Groundhog Day on /. every time this comes up!

"The Internet is not ports, it's not machines, it's not protocols. We could change all that and it could still be the Internet. The Internet is a philosophy, and the results of that philosophy. It's about making a good faith best effort to connect to and exchange information with anyone else who makes a similar effort."
From this nanog post.

I usually don't reply to people this stupid. But it's a slow night.

The 'byte stream' model is not from UNIX, its just the way the hardware is laid out physically.

No, the hardware isn't laid out that way. The byte stream model is a software-implemented convenience to hide things like disk blocks and packet sizes. There's overhead associated with that, in several senses. You usually have to impose some protocol on top of the stream just to define the boundaries between items. There have been non-UNIX systems where files were record-oriented, rather than stream-oriented. UDP is transaction-oriented, although the transactions aren't reliable. QNX messaging is transaction-oriented and reliable, yet a transaction maps to one network packet if possible.

RDMA is pretty much a stable of high speed cluster computing, however its DMA that allows pretty much everything in your PC to work without slowing the processor down. Even your keyboard controller uses DMA to get the characters into somewhere useful.

Actually, DMA is part of the problem. The trouble is that most DMA is applied to real memory addresses; it doesn't pass through the MMU. This is a historical artifact of the minicomputer and PC world, which for cost reasons didn't have channel controllers like mainframes. As a result, DMA has to be managed by the OS. On IBM mainframes, the OS could give an application hardware access to a dedicated raw device, and that didn't allow the application to write outside its process, because the channel controller's memory mapping was set up by the OS.

Now that transistor counts in I/O controllers are no longer an issue, it's worth rethinking this. With the right hardware, two applications on different machines should be able to communicate safely without OS intervention.

As far as what you're calling RDMA via Infiniband, I've seen massive clusters (some of the largest in the world) using it ... safely.

Current Linux support for RDMA exists but has problems. RDMA and paging do not play well together. There's a proposal to put support for something like that into Linux, but it's really ugly. It's called "ummunotify", which is intended to notify processes when their MMU state is being changed by the kernel. This is so they can coordinate with the other machine that has RDMA access into their address space.

Personally, I think it's time to get rid of paging. Historically, paging systems at best yield the effect of having twice as much RAM, and RAM is so cheap today as a fraction of system cost that it's a nonissue. If you don't have to worry about page fault delays, performance is far more repeatable.

"The OSI certification made it mandatory for source code to be made available. Else, the certification will be revoked. Read the OSD again at http://opensource.org/docs/osd and burn the document contents on your mind. With BSD license, making the source code available IS MANDATORY!"

1. It's not in the license.
2. Still doesn't mean people down the chain can necessarily get at it, and they certainly aren't guaranteed access to derived code.
3. You might want to check out this thread in which it is discussed and people come to the conclusion the the OSI term "source must be available" refers to whether a piece of software is open source, not a given license.

"With many companies and individuals listed in my previous post out there, I dare say I am living in col-hard reality!"

Yet end users still don't have the freedom to get the source code for derived versions under the BSD license, a freedom granted under GPL, and a freedom you don't consider worth protecting. I don't consider the freedom to make closed derivatives worth protecting.
If you still don't accept that GPL and BSD provide different freedoms for different people, well, I've done my best. You're still wrong.

He tried that before. I think he's given up on getting his scheduler (though perhaps not a suspiciously similar one written by Inigo) in the kernel after what happened with CFQ.

One reason for why the principle of CFS may seem to you so suspiciously similar to Con's SD scheduler is that i used Con's fair scheduling principle when writing the initial version of CFS. This is credited at the very top of today's kernel/sched.c [the scheduler code]:

  * 2007-04-15 Work begun on replacing all interactivity tuning with a
  * fair scheduling design by Con Kolivas.

It was added in this commit.

The scheduler implementations (and even the user visible behavior) of the schedulers was and is very different - and there is where much of the disagreement and later flaming came from.

Note that this particular Slashdot article is about IO scheduling though - which is unrelated to CPU schedulers. Neither Con nor i wrote IO schedulers.

There are two main IO schedulers in Linux right now: CFQ and AS, written by Jens Axboe, Nick Piggin, et al.

What adds fuel to the confusion is that it is relatively easy to mix up 'CFQ' with 'CFS'.

Thanks,

Ingo

That's why I suggested this years ago:
http://lists.w3.org/Archives/Public/www-html/2002May/0021.html
http://www.mail-archive.com/mozilla-security@mozilla.org/msg01448.html

I think mozilla are finally trying to do something about it:
https://developer.mozilla.org/en/Security/CSP

But after so many years, worms and exploits...