Slashdot Mirror

I'll bite. The main reasons I consider using FreeBSD nowadays are:

1) Reasonable filesystem support. ext3 and ext4 are just terrible filesystem for 24x7 production systems. The potential for long fsck times alone is enough to remove them from a lot of serious applications. XFS does better, but with its lack of popularity the user base is a little scary. Meanwhile, FreeBSD has ZFS, which is just a better filesystem that almost any other choice. And it also has UFS2, which avoids the whole "let's keep the server down while we do a long filesystem check sometimes" problem Linux suffers with by doing background fsck.

2) The new FreeBSD 8.2 includes userland DTrace support, which has been the missing piece that has kept earlier verisons from replacing Solaris for me on a lot of systems. systemtap on Linux just completely misses the point from a complexity and "scary" perspective. It just doesn't have that feel that you're not going to hurt the running process by using it that DTrace has always managed.

If there's a USA wish/murmur to combat bad things on the internet, why not pull another Tor and fund development of things like DNCCurve/CurveCP through this?

I heard it mentioned in the "Vulnerable Compliance" talk mentioned here: http://www.usenix.org/events/sec10/tech/

It's in the video at 54:45. Dan Geer references an exchange with an anonymous party.

There are utilities who really want to ship meters with dozens of MB of firmware images, all compressed, all actually used, no partial update, while having under 10 kbits of bandwidth to the meters. Note carefully that the rationale for doing this as currently designed is that it is all conforming to industry standard protocols that have been tested and vetted.

Unfortunately, Usenix wants registration for the actual video. It's a really interesting talk for those who are interested in big picture of network protocol security (I give part of it :-) If people really care, perhaps I could smuggle an excerpt on YouTube or something. Track down my email and email me.

Open standards are very similar to units of measure in this respect and we can all imagine what things would be like if we didn't operate from the same ones...

I can imagine airplanes falling out of the sky. As can Air Canada, if they remember the Gimli Glider incident (see http://en.wikipedia.org/wiki/Gimli_Glider)

You can also hear Dan Klein tell a story about it (and software testing in general) at http://www.usenix.org/events/usenix05/tech/mp3/klein.mp3

Pollack's presentation.

One thing about SSDs make this problem easier to solve.

I understand this is Slashdot and all, and it would be very politically incorrect to ask the editors to read the original paper about the attack, much less understand it... but, for God's sake, the paper starts with a demo of this attack on JSF (which has precisely the same issues as ASP.NET)! There's also a presentation devoted entirely to attacking JSF apps with this.

And starting from there, I'll just quote:

Besides JavaServer Faces, we have also audited someother popular web frameworks to see if they are vulnerable to padding oracle attacks. Here are some of our findings.

Since version 2.3, Ruby On Rails has introduced ActiveSupport::MessageEncryptor which is a set of functions to provide a simple way to encrypt information for storage in an untrusted location (like cookies). If you look at ActiveSupport::MessageEncryptor's source code,
you would probably see that applications that use the provided encrypt/decrypt functions would be vulnerable to padding oracle attacks.

The reason why ASP.NET is most affected by this in practice is because there are many more clueless developers who enable full exception information being passed to the client in production (and that, in turn, is largely because ASP.NET is a common tool of choice for outsourcing bids).

You have the source. You can compile it yourself. If it doesn't work the way you'd like, you can change it.

Sure, but the glacial pace at which Gallium3D and its drivers advance is a testimony to how hard it must be to write a graphics driver. If it was a job for your average programmer, the guys working on this stuff would have given us functional drivers two years ago. At this pace you'll be able to enjoy stable and fast R700 hardware support another 3 years from now.

In the future, when those drivers are done, they will surely be benefits to them being open source. But the only actual benefit now would be if some ingenious hacker got involved, committed and wrote the drivers in a couple months. Currently the development model isn't working very efficiently, because R600 docs were released over 2 years ago and we're only beginning to see functional drivers.

Open source works better when the barrier to involvement is lower, OpenGL infrastructure is more complex than most kernel drivers. It requires:
* knowing the OpenGL API intimately
* a firm grasp of 3D math and rasterization process
* an idea how to manage non-uniform memory and do low level hardware access in a thread-safe way
* a fair bit of compiler design for compiling shaders to GPU instructions
* all of the above done in C, because we still haven't developed a better language for low level work (see this paper for things a driver design language could have)

If everything is running in kernel space, you've given up all the advantages of a microkernel.

Not when you use SIP.
http://research.microsoft.com/en-us/projects/singularity/

NT is a "hybrid" microkernel just like Darwin, which gets it the worst of both worlds.

Not acording Microsoft OS reseachers what said that NT use pure microkernel, like Singularity as well. And Darwin is not OS, XNU is. Darwin is XNU + Apples official compilation tools. When you download the Darwin package, you get the tools, XNU OS what is separated to Mach microkernel, I/O Kit and BSD parts and so on. You can compile XNU with own compilation tools if wanted, without the Apple's. But you do not get it work with Mac OS X closed ABI then. You need to know exact Darwin version to know XNU was compiled.

DragonFly has message passing tacked on, but isn't a microkernel as far as I'm aware

It has microkernel, just different way than original idea to implent Server-Client architecture. There is no such thing as "hybrid" in scientifical means, only in marketing.

L4Linux might be interesting if they aren't just using it as a hypervisor, I'll have to look into it.

Idea is to run Linux OS on VM (what L4 would be) and achieve by that faster way to load Linux OS when it crash. It is interesting idea but does not really solve any problems what the monolithic OS can have (!can!) and what reason the Server-Client architecture was done in the first place. The OS still runs in L4Linux as monolithic but just in user space. So it can help to speed up servers downtime when OS crash with few seconds.

http://www.usenix.org/publications/login/2006-04/openpdfs/herder.pdf

This exists, and it's called Scantegrity. At USENIX Security last week (where the Pac-Man demo was unveiled), there was a paper reporting on their experience deploying Scantegrity in a real binding government election.

You must have a random per-account salt to stop brute-force attacks of your entire password database. Doing so multiplies the cost of cracking the passwords by the number of accounts.

Someone who has your password database probably has your system salt. They can generate a hashtable from that and crack a good number of your passwords very quickly. When using random per-account salts, however, they can't use a hash table or rainbow table. They have to perform a complete brute-force against every single hash.

It is also a mistake to use a cheap hash function, like SHA. You should use an expensive one, like bcrypt.

http://www.usenix.org/event/usenix99/provos/provos_html/index.html

(ps: you are not talking to just another programmer. you are talking to an infosec specialist.)

You are correct, The cheap snapshots didn't come till ufs2 when Mckusick added the functionality. Much of the fs structure allowing such functionality was in place long before though like pointers and the upper/lower container layers of UFS. NetApp obviously did that well before BSD's and Solaris as well as some other things. My point is they were standing on the shoulders of giants to achieve it.

http://www.usenix.org/event/bsdcon02/mckusick/mckusick_html/

I'll take your word on the 94 NetApp usage, as I was still a few years away from even knowing what shell account was.

I understand about strcpy being unsafe, but strncpy() has the size parameter, so it will only copy bytes.

The problem with strncpy is that it is not guaranteed to null-terminate - it pads with '\0' at the end if there is space in the destination buffer, but if the length matches precisely, it will not pad. So to use it safely, you need to put a '\0' at the very end of the buffer yourself, and tell strncpy that there is 1 less byte there than there actually is, so that the terminator is never overwritten. Again, people tend to get this wrong more often than not.

In addition, it is also time-inefficient due to the fact that it fills the entire remaining buffer with '\0', rather than just adding a single `\0` to terminate.

Indeed, OpenBSD also introduced strlcpy (and friends) for precisely these reasons.

I was at LISA '09, and Dr. Bruno Michel (works for IBM, mentioned in the article) made a presentation on this work (or at least very, very similar work). You can see the presentation, or download the MP3, here:

http://www.usenix.org/event/lisa09/tech/tech.html#michel

Interesting talk, and well worth your time.

I was at LISA '09, and Dr. Bruno Michel (works for IBM, mentioned in the article) made a presentation on this work (or at least very, very similar work). You can see the presentation, or download the MP3, here:

http://www.usenix.org/event/lisa09/tech/tech.html#michel

Interesting talk, and well worth your time.

A. Overview of Objective-C

Objective-C is a layer on top of C [6, 17]. It supports classes and message passing paradigms similar to Smalltalk. Describing Objective-C in detail is outside the scope of this paper. Here we give only a brief overview of Objective-C, which is based on the Objective-C FAQ in http://www.yahoo.com/Computers/Languages/Objective_C/. The main characteristics of Objective-C are:

• It is compiled.
• It has a dynamic runtime system (objects are dynamically typed). Full type information (name and type information of methods and instance variables and type information of method arguments) is available at run time.
• Classes and methods can be added (dynamically loaded) at runtime.
• There is one root class Object from which all other classes inherit. (This is not quite true; other root classes can be defined, e.g., NSProxy in OpenStep.)
• Method/message syntax is similar to Smalltalk.
• Unlike in Smalltalk, there is no garbage collection. Instead, reference counting pseudo-garbage collection techniques are typically used.

I am badly late on this topic, but I couldn't help to comment. Here's a link to public-key based firewall: http://www.usenix.org/event/usenix07/posters/lindqvist.pdf The idea is to ditch IP address-based access control lists in firewalls and to favour public-key authentication to support mobile devices. The approach is also based on end-to-end VPN rather than the popular end-to-middle VPNs. Here's a longer journal article: http://www.igi-global.com/Bookstore/Article.aspx?TitleId=39054

http://www.usenix.org/publications/library/proceedings/tcl96/full_papers/korn/

Anyone know what happened to it? I remember looking forward to it a long time ago but have since moved to python.

In 1997 DEC's own guys said that the FX!32 system could run an x86 NT4 application on a 500MHz Alpha about as fast as that application would run on a 200MHz Pentium Pro. Given that they were DEC guys; but not DEC marketing guys, I'd assume that the (unnamed) application chosen was flattering but not an outright lie.

Given that ARM cores are generally weaker, even the nice ones; but cheaper and lower power than X86s, I shudder to think how such a system would work for a situation where legacy X86 code was being run on some weedy smartbook.

• Subscribe to FLOSS & related organisations and publications, eg: Linux Weekly News, Usenix, Free Software Foundation, ...
• Leave the publications around for people to read
• Go to conferences, send others in your dept to conferences
• Get together with related Govt organisations and see what s/ware you can share; set up a common repository; making that repository world visible (may be harder)
• If you produce interfaces for the public to use, fully document them so that FLOSS applications can use them

From http://www.usenix.org/events/nsdi/tech/full_papers/cully/cully_html/index.html

We then evaluate the overhead of the system on application performance across very different workloads. We find that a general-purpose task such as kernel compilation incurs approximately a 50% performance penalty when checkpointed 20 times per second, while network-dependent workloads as represented by SPECweb perform at somewhat more than one quarter native speed. The additional overhead in this case is largely due to output-commit delay on the network interface.

Based on this analysis, we conclude that although Remus is efficient at state replication, it does introduce significant network delay, particularly for applications that exhibit poor locality in memory writes. Thus, applications that are very sensitive to network latency may not be well suited to this type of high availability service (although there are a number of optimizations which have the potential to noticeably reduce network delay, some of which we discuss in more detail following the benchmark results). We feel that we have been conservative in our evaluation, using benchmark-driven workloads which are significantly more intensive than would be expected in a typical virtualized system; the consolidation opportunities such an environment presents are particularly attractive because system load is variable.

So with 20 checkpoints a second you turn a normal compile time into twice as long as the original time. With a web server, just serving web pages and not pulling data off an external database you're doing to 25% or the original speed. If you throw in database access its not just going to be 25% of 25%, its going to be far worse due to the two way communications with the database having to wait on checkpointing.

Thats at 20 checkpoints a second, at 1-2 seconds per checkpoint I imagine the kernel compile would probably go faster if you're not using NFS, but networked IO is going to be unusable.

Its cool that you've done it, but its really not useful for many applications.

From a Remus whitepaper:

http://www.usenix.org/events/nsdi/tech/full_papers/cully/cully_html/index.html

We then evaluate the overhead of the system on application performance across very different workloads. We find that a general-purpose task such as kernel compilation incurs approximately a 50% performance penalty when checkpointed 20 times per second, while network-dependent workloads as represented by SPECweb perform at somewhat more than one quarter native speed. The additional overhead in this case is largely due to output-commit delay on the network interface.

Based on this analysis, we conclude that although Remus is efficient at state replication, it does introduce significant network delay, particularly for applications that exhibit poor locality in memory writes. Thus, applications that are very sensitive to network latency may not be well suited to this type of high availability service (although there are a number of optimizations which have the potential to noticeably reduce network delay, some of which we discuss in more detail following the benchmark results). We feel that we have been conservative in our evaluation, using benchmark-driven workloads which are significantly more intensive than would be expected in a typical virtualized system; the consolidation opportunities such an environment presents are particularly attractive because system load is variable.

50% performance lost for non-network IO applications, only 1/4 original speed for a normal web hit, not using a database to generate data on the page. This is well outside any acceptable level of performance for anything more than a toy/example.

Here's a bit of background the /. editors didn't give you.

If you take a 2-second look at the paper (the pdf link in the summary), you see Matt Blaze's name.

He's been doing other work on making law enforcement wiretapping not work. For instance, go to http://www.usenix.org/events/sec06/tech/ and search the page for "Blaze"; you should find his talk (http://www.usenix.org/events/sec06/tech/mp3/blaze.mp3) and the Q&A session.

He also gave essentially the same talk as the first (under a different title) at http://www.usenix.org/event/lisa05/tech/ (again, search the page for "Blaze" or go straight to http://www.usenix.org/event/lisa05/tech/mp3/blaze.mp3).

He also spoke at hotsec06, http://www.usenix.org/events/hotsec06/tech/, with no recorded mp3, and at an e-voting panel, http://www.usenix.org/events/sec07/tech/.

As you might infer, this isn't the first time Mr. (Dr.?) Blaze has been studying wiretapping (or other security issues). He's also quite a good, entertaining speaker. I recommend giving him a listen.

The short story (from the usenix talks): press the "C" key on your old 4x4-keypad phone. That's the in-band signal (doh!) used by law enforcement to mean "don't record now". Or, look up the tone frequency, then play it back at a much lower volume with a tone generator (your laptop might do) so it's more comfortable to talk over.

Here's a bit of background the /. editors didn't give you.

If you take a 2-second look at the paper (the pdf link in the summary), you see Matt Blaze's name.

He's been doing other work on making law enforcement wiretapping not work. For instance, go to http://www.usenix.org/events/sec06/tech/ and search the page for "Blaze"; you should find his talk (http://www.usenix.org/events/sec06/tech/mp3/blaze.mp3) and the Q&A session.

He also gave essentially the same talk as the first (under a different title) at http://www.usenix.org/event/lisa05/tech/ (again, search the page for "Blaze" or go straight to http://www.usenix.org/event/lisa05/tech/mp3/blaze.mp3).

He also spoke at hotsec06, http://www.usenix.org/events/hotsec06/tech/, with no recorded mp3, and at an e-voting panel, http://www.usenix.org/events/sec07/tech/.

As you might infer, this isn't the first time Mr. (Dr.?) Blaze has been studying wiretapping (or other security issues). He's also quite a good, entertaining speaker. I recommend giving him a listen.

The short story (from the usenix talks): press the "C" key on your old 4x4-keypad phone. That's the in-band signal (doh!) used by law enforcement to mean "don't record now". Or, look up the tone frequency, then play it back at a much lower volume with a tone generator (your laptop might do) so it's more comfortable to talk over.

Here's a bit of background the /. editors didn't give you.

If you take a 2-second look at the paper (the pdf link in the summary), you see Matt Blaze's name.

He's been doing other work on making law enforcement wiretapping not work. For instance, go to http://www.usenix.org/events/sec06/tech/ and search the page for "Blaze"; you should find his talk (http://www.usenix.org/events/sec06/tech/mp3/blaze.mp3) and the Q&A session.

He also gave essentially the same talk as the first (under a different title) at http://www.usenix.org/event/lisa05/tech/ (again, search the page for "Blaze" or go straight to http://www.usenix.org/event/lisa05/tech/mp3/blaze.mp3).

He also spoke at hotsec06, http://www.usenix.org/events/hotsec06/tech/, with no recorded mp3, and at an e-voting panel, http://www.usenix.org/events/sec07/tech/.

As you might infer, this isn't the first time Mr. (Dr.?) Blaze has been studying wiretapping (or other security issues). He's also quite a good, entertaining speaker. I recommend giving him a listen.

The short story (from the usenix talks): press the "C" key on your old 4x4-keypad phone. That's the in-band signal (doh!) used by law enforcement to mean "don't record now". Or, look up the tone frequency, then play it back at a much lower volume with a tone generator (your laptop might do) so it's more comfortable to talk over.

Here's a bit of background the /. editors didn't give you.

If you take a 2-second look at the paper (the pdf link in the summary), you see Matt Blaze's name.

He's been doing other work on making law enforcement wiretapping not work. For instance, go to http://www.usenix.org/events/sec06/tech/ and search the page for "Blaze"; you should find his talk (http://www.usenix.org/events/sec06/tech/mp3/blaze.mp3) and the Q&A session.

He also gave essentially the same talk as the first (under a different title) at http://www.usenix.org/event/lisa05/tech/ (again, search the page for "Blaze" or go straight to http://www.usenix.org/event/lisa05/tech/mp3/blaze.mp3).

He also spoke at hotsec06, http://www.usenix.org/events/hotsec06/tech/, with no recorded mp3, and at an e-voting panel, http://www.usenix.org/events/sec07/tech/.

As you might infer, this isn't the first time Mr. (Dr.?) Blaze has been studying wiretapping (or other security issues). He's also quite a good, entertaining speaker. I recommend giving him a listen.

The short story (from the usenix talks): press the "C" key on your old 4x4-keypad phone. That's the in-band signal (doh!) used by law enforcement to mean "don't record now". Or, look up the tone frequency, then play it back at a much lower volume with a tone generator (your laptop might do) so it's more comfortable to talk over.

Here's a bit of background the /. editors didn't give you.

If you take a 2-second look at the paper (the pdf link in the summary), you see Matt Blaze's name.

He's been doing other work on making law enforcement wiretapping not work. For instance, go to http://www.usenix.org/events/sec06/tech/ and search the page for "Blaze"; you should find his talk (http://www.usenix.org/events/sec06/tech/mp3/blaze.mp3) and the Q&A session.

He also gave essentially the same talk as the first (under a different title) at http://www.usenix.org/event/lisa05/tech/ (again, search the page for "Blaze" or go straight to http://www.usenix.org/event/lisa05/tech/mp3/blaze.mp3).

He also spoke at hotsec06, http://www.usenix.org/events/hotsec06/tech/, with no recorded mp3, and at an e-voting panel, http://www.usenix.org/events/sec07/tech/.

As you might infer, this isn't the first time Mr. (Dr.?) Blaze has been studying wiretapping (or other security issues). He's also quite a good, entertaining speaker. I recommend giving him a listen.

The short story (from the usenix talks): press the "C" key on your old 4x4-keypad phone. That's the in-band signal (doh!) used by law enforcement to mean "don't record now". Or, look up the tone frequency, then play it back at a much lower volume with a tone generator (your laptop might do) so it's more comfortable to talk over.

``A microkernel architecture for devices least able to afford the overhead'' What overhead? The way I understand it, the overhead typically associated with microkernels comes two sources: overhead incurred when transferring control across process boundaries and inefficiency of the implementation. Inefficiency of the implementation (e.g. using a complex message-passing system that consumes many CPU cycles) is a problem, but it's not intrinsic to microkernels. Overhead incurred when transferring control across process boundaries depends on many factors, such as what your OS's idea of "process" is, how this is mapped to the constructs provided by the hardware, and how efficient the hardware implementation is. Long story short, implementing processes as tasks on x86 hardware and using the MMU to separate processes' address spaces is very inefficient. An implementation on an MMU-less system with an ARM CPU and all processes in the same address space would not be nearly as inefficient. In fact, on an ARM CPU, even with an MMU and processes in separate address spaces, one study (PDF) has measured the context switching overhead of Linux to be up to 0.25%. If Linux can do that, a microkernel can, too. Now, I don't know about you, but 0.25% isn't enough to keep me awake with worry all night. All in all, I think the reputation that microkernels have for introducing a lot of overhead is simply due to inefficient implementations on inefficient hardware. I also wonder how much kernel efficiency still matters these days; it seems that most programs seem to fall in one of 3 categories: 1) mostly sitting idle waiting for input (user input, disk reads, memory access) 2) bound mostly by the speed of the graphics card 3) spending most of their CPU cycles in their own code or libraries. System call overhead has little impact on these programs ...

How curious. The first sentence or two were the best ones:

Nominum Releases BIND 9

Oct 06 2000

Redwood City, California -- October 6, 2000 -- The Internet Software Consortium (ISC) has announced the release of BIND 9, written by Nominum, Inc. [...]

For the rest, you can just trust that USENIX won't try to rewrite their own history any time soon.

Kohath / Techno-vampire commented "IT people setup security that's needlessly inconvenient". A paper from HotSec '07 http://www.usenix.org/event/hotsec07/tech/full_papers/florencio/florencio.pdf titled "Do Strong Web Passwords Accomplish Anything?" addresses the principal of requiring users to use ridiculously strong passwords. In practice, this tends to have the adverse effect by making systems too cumbersome to log into and passwords that are so hard to remember they are often written down. How strong do passwords need to be in order to be effective? The paper argues (and the math confirms) that even relatively weak passwords (20 bits) when used with password rotation and "three strike" policies are enough to make brute-force attacks on a single account unrealistic. My employers previous user/pass policy was mixed case, 8 char min, #'s and punctuation requirement, with 90 day rotation and three-strikes - BUT the username was made public, so only 1/2 the credential pair was private. My approach was to make both the user and the pass non-public, keep the rotation & three-strike policy and reduce the complexity requirement of the password slightly. The result puts more of the security burden on the systems and less on the users (by not having to remember complex passwords). This results in higher overall security of credential pairs and made the userâ(TM)s daily experience easier and less cumbersome.

Wrong. BSD's are operating systems just like the Linux is too.

All BSD's are monolithic kernels like Linux. The monolithic kernel is complete operating system. While the microkernel is just part of the operating system.

In history, the operating system has be always the kernel, what was called supervisor, master program, core and so on as well.

Then there came new idea to build OS as modular what would be more stable and secure. So born the server-client arcitechture idea what is called microkernel. The monolithic Operating System is sliced to parts. Small microkernel + it's servers. The servers can be moved to userspace or kept on the kernel space. But they are not part of the kernel itself anymore.

The distribution is not operating system. It is the term used for one operating system what is used on multiple different /software systems/.
The Linux kernel, is raped by GNU propaganda by trying to make it look like microkernel. GNU people is trying to twist the truth about Linux and Hurd. Hurd is operating system like the Linux. But what GNU people do not like to tell, is that Hurd's kernel is microkernel called GNU Mach. They try to tell that kernel has kernel inside it. Hurd is microkernel + OS servers. There is no such operating system called GNU/Linux or GNU/Hurd (or GNU/kFreeBSD). There is development platroforms called GNU/Linux (Linux OS + GNU compile tools), GNU/Hurd (Hurd OS + GNU compile tools) and GNU/kFreeBSD (FreeBSD OS + GNU compile tools).

Everytime you say that "linux is just a kernel". You mean that Linux is a microkernel. That is just pure lie. If you want to be correct, you speak about Linux and you can call it as Linux operating system or Linux kernel, but it is always only the operating system. Monolithic kernel.

http://www.usenix.org/publications/login/2006-04/openpdfs/herder.pdf

People does not know that *BSD's are monolithic OS's as well. Just like Linux. BSD's own good thing is that they do not have grazy group of people like GNU to spread own propaganda for fame hunting.

Netapp released a study as well that included enterprise targeted drives, and in some cases the fiber-channel drives had significantly better error rates. The other interesting studies here are from Google and Carnegie Mellon

A backdoored BIOS is for newbies. The real hardcore hackers use back-doored CPUs or other hardware. All it has to do is look at a packet with a certain byte sequence and its pwned.

An unsettling read, but at least it proves that computer and electrical engineering trumps "software" engineering.;)

A backdoored BIOS is for newbies. The real hardcore hackers use back-doored CPUs or other hardware. All it has to do is look at a packet with a certain byte sequence and its pwned.

Sure it can. And then someone can use techniques such as MFM, SPM or STM to recover the disk. And then there is this patent which notes that data is often partially written off the track, and thus can't be wiped.

I guess for most people's purposes something like DBAN will work well. But for the truly paranoid, you really need to read NIST's recommendation that you clear, purge and destroy. And by destroy, they mean that you use "Disintegration, Pulverization, Melting, and Incineration." At a "outsourced metal destruction or licensed incineration facility with the specific capabilities to perform these activities effectively, securely, and safely", no less.

Well, it does not matter what structure you have used to build your OS. It will come down if the kernel comes. The problem really is huge on monolithic OS's, like Linux and *BSD. One giant OS in kernel space what includes all drivers and other parts. The theory is that modular OS, build with microkernel would be much safer and stable. Idea is great but problem is that you can even do same kind things on monolithic OS to protect it's kernel and drivers from each other.

http://www.usenix.org/publications/login/2006-04/openpdfs/herder.pdf

Most OS crashes comes because the driver crash. Because monolithic OS has drivers inside itself. You are "totally" in deep shit. But if you get driver bugs cleaned away, no problems...

Well, kernel bug brings down whole OS and all the applications running top of it. But the kernel is usually most secure and stable. Most errors comes from drivers.

http://www.usenix.org/publications/login/2006-04/openpdfs/herder.pdf

And that is the problem with the monolithic OS's. One bug in the driver or any other part of the OS, brings it down. But even it is about monolithic OS, it can be as secure as microkernel-based OS's like Hurd, Minix or NT.

And I believe that the star of the next 10 years will come to be the MS Singularity.

Better: http://www.usenix.org/event/evt07/tech/full_papers/riva/riva_html/

From a management perspective, that IT department is what the magic cloud will substantially replace. Software as Service means no expensive hardware to own and no expensive IT staff. Well, a reduction in SysAdmins anyway. Spending money on core-competencies blah blah blah. There's work being done to make cloud hosted data secure - see

http://www.usenix.org/events/hotcloud09/tech/

Yes, I work for USENIX.

FAST 2009 has a paper on semantic data management using a file system built on top of an object store powered by MySQL. Performance isn't great, but it uses a distributed file system solution to solve the synchronization issue in a very nice way (e.g., synchronize all albums with my iPod, all photos with my laptop and computer, etc...). You can specify rules and I liked it when I heard about it. However performance is actually important, despite their claim :). Perspective: Semantic Data Management for the Home Brandon Salmon, Carnegie Mellon University; Steven W. Schlosser, Intel Research Pittsburgh; Lorrie Faith Cranor and Gregory R. Ganger, Carnegie Mellon University HTML Paper http://www.usenix.org/events/fast09/tech/full_papers/salmon/salmon_html/index.html PDF Paper http://www.usenix.org/events/fast09/tech/full_papers/salmon/salmon.pdf Slides http://www.usenix.org/events/fast09/tech/slides/salmon.pdf

FAST 2009 has a paper on semantic data management using a file system built on top of an object store powered by MySQL. Performance isn't great, but it uses a distributed file system solution to solve the synchronization issue in a very nice way (e.g., synchronize all albums with my iPod, all photos with my laptop and computer, etc...). You can specify rules and I liked it when I heard about it. However performance is actually important, despite their claim :). Perspective: Semantic Data Management for the Home Brandon Salmon, Carnegie Mellon University; Steven W. Schlosser, Intel Research Pittsburgh; Lorrie Faith Cranor and Gregory R. Ganger, Carnegie Mellon University HTML Paper http://www.usenix.org/events/fast09/tech/full_papers/salmon/salmon_html/index.html PDF Paper http://www.usenix.org/events/fast09/tech/full_papers/salmon/salmon.pdf Slides http://www.usenix.org/events/fast09/tech/slides/salmon.pdf

FAST 2009 has a paper on semantic data management using a file system built on top of an object store powered by MySQL. Performance isn't great, but it uses a distributed file system solution to solve the synchronization issue in a very nice way (e.g., synchronize all albums with my iPod, all photos with my laptop and computer, etc...). You can specify rules and I liked it when I heard about it. However performance is actually important, despite their claim :). Perspective: Semantic Data Management for the Home Brandon Salmon, Carnegie Mellon University; Steven W. Schlosser, Intel Research Pittsburgh; Lorrie Faith Cranor and Gregory R. Ganger, Carnegie Mellon University HTML Paper http://www.usenix.org/events/fast09/tech/full_papers/salmon/salmon_html/index.html PDF Paper http://www.usenix.org/events/fast09/tech/full_papers/salmon/salmon.pdf Slides http://www.usenix.org/events/fast09/tech/slides/salmon.pdf

"Performance" can be viewed as creating value. But at what cost? In the IT world, cost and value are often measured in incommensurate units. Once you get a handle on cost you can start to tackle value. I recommend starting at http://www.usenix.org/event/lisa05/tech/couch.html

Paper here: http://www.usenix.org/events/usenix09/tech/full_papers/toomey/toomey.pdf

Program here: http://www.usenix.org/events/usenix09/tech/

Yes, I work for USENIX.

Paper here: http://www.usenix.org/events/usenix09/tech/full_papers/toomey/toomey.pdf

Program here: http://www.usenix.org/events/usenix09/tech/

Yes, I work for USENIX.

Almost no RAID systems can do what ZFS does. Hints: end to end checksumming; self-healing; copy on write; ...

No. This is missing from RAID-on-a-card and software raid like LVM2, but, NetApp Hitachi and EMC all have checksums and all do self-healing. See

(1)
(2)
(3).

ZFS pundits make a big deal about the ``end-to-end"" nature of their checksums, but the storage vendors design aroudn actual observed failures while the ZFS pundits tend to tell anecdotal war stories or defend against hypothetical problems. It's good that ZFS has protection from the failures their competitors have discovered, but the aggressive punditry is dishonest FUD.

NetApp does COW and has similar high-performing snapshots/clones at the cost of needing a defragmenter for databases to stay fast. However NetApp has said defragmenter and ZFS doesn't.

Lack of imagination.

For example, consider a commit-or-verify scheme. After you cast a ballot you can either commit the ballot or verify that it was recorded correctly and repeat the process.

Check out VoteBox:
http://www.usenix.org/events/sec08/tech/full_papers/sandler/sandler_html/index.html

Each guest needs its own kernel, so you need to allocate memory and disk space for all these kernels that are in fact identical

I'm pretty sure VMWare can detect when the same block of the same file is mapped into multiple guests, and share the physical page. Plus, the kernel's memory image is small compared to, say, the database server you're running on it. I guess there's overhead like an extra set of page tables (either nested page tables managed by the guest, or shadow page tables managed by the host). Overall a small effect I think.

TLB flushes kill performance. Recent x86 CPUs address the problem to some degree, but it's still a problem.

Any context switch between two userspace programs in a non-virtualized system needs a TLB flush too (BSD jails included). Or, if you're using a processor that has a tagged TLB, you don't need to flush it, but your virtualized guest gets the no-TLB-flush benefit too.

A guest's filesystem is on a virtual block device, so it's hard to get at it without running some kind of fileserver on the guest

Again I don't think this is a huge deal. Aren't there drivers to allow a host to see inside a guest's block device and/or filesystem?

Memory management is an absolute clusterfuck.

In a naive hypervisor, yes. In more mature hypervisors, not really. See the following articles for solutions on fully virtualized and paravirtualized guests, respectively: http://www.usenix.org/events/osdi02/tech/waldspurger/waldspurger_html/node6.html
http://lwn.net/Articles/198380/

Cell carriers used scheduled access to the wireless channel, which provides guarantees on bandwidth and latency so that your speech is understandable. 802.11 provides random access, which is great for bursty Web traffic but terrible for voice when multiple people use it simultaneously (and undoubtedly you would not be the only one using VOIP over your WiMax AP).

For example, an 802.11b network can handle ~140 simultaneous Skype calls in theory, but only about 6 in practice. For a more detailed analysis, see this paper

http://www.usenix.org/event/lisa07/tech/full_papers/hamilton/hamilton.pdf

Dig all his papers:
he talks about using IBM cooling-on-the-hot-bits RACKS,
instead of building up your own,
so you just roll in 50 racks & lock 'em down, connect 'em, and fire 'em up.

He says organize by service, not by HW.

he says never shut down a server by "shutting it down", but instead by the power-switch, to make certain that failover works right, pervasively...

if you've got empty space because cooling/power is the limit, then spending on denser servers is stupid.

lots of gold in his writings...

goggle his other stuff, if y'all like...

Cheers,

Captain Obvious

Found the reference I was talking about:

            Author: Allan Bricker
            Author: Morgan Clark
            Author: Tad Lebeck
            Author: Barton P. Miller
            Author: Peter Wu
              Title: Experiences with DREGS
              Pages: 471-481
      Publisher: USENIX
  Proceedings: USENIX Conference Proceedings
                Date: Summer 1987
        Location: Phoenix, AZ
  Institution: University of Wisconsin

From here http://usenix.org/publications/bibliography/byDate.html

dunno if it's available anywhere online now...
I seem to recall that "DREGS" stood for Distributed Realtime Environment for Game Systems but that was ~22 years ago, not really sure any more.