Slashdot Mirror

(What are the chances of two Alan Coxes in this field of business!? Bummer for the other Alan Cox. Probably often mistaken as Linus' lieutenant...)

There is a very interesting presentation on the design and development of windows NT/2000 presented on USENIX here (google HTML rendition here). I love to bash Microsoft too, but reading it, there are at least some decisions that I think they did right.

fyi, he's speaking at the Usenix Technical Conference on June 12th as the keynote speaker. he's going to talk about this new book and some other things. luckily, i'll be there =)

This may not stop spam, but could make email a much safer medium. Most people have no idea how insecure plaintext email is. Having encryption transparent from the user would be a significant step in the right direction. From the OE docs:


"Only one current product we know of implements a form of opportunistic encryption. Secure sendmail will automatically encrypt server-to-server mail transfers whenever possible."


Unfortunately the linked paper is from 1999 and there does not seem to be any updated information.

Adi Gadwale.

But my setup uses ipfw and not as in the example pf, I am not sure it's possible to setup ALTQ with ipfw (ideas are welcome!!). IPFW does support bandwith throttling in combination with Dummynet.

Here is another white paper I found: Managing traffic with ALTQ.

The two previous postings in this thread both make excellent points. In common with both is the insight that security has to be addressed foremost in terms of design principles. The first posting discussed the principle of verifiability (the system keeps its word.) The second posting discussed consistency with respect to the requirements set by security policy.

It's not very productive to try to reason about the security of a system if we can't be certain how it was built, yet typically sites cannot say with certainty whether or not any of their hosts match a given definition of how they were to have been configured[1]. Similarly, the correspondence between policy and practice is ultimately a product of human effort, so that even with a clear and meaningful site policy in place, its effectiveness will tend to be adversely influenced by human factors [2]. Unfortunately it seems from some studies that only a very small minority of sites have developed security policies at all [3].

It's common for people at the outset to discuss security in terms of promoting a shopping list of specific security elements and practices. Indeed, it's probably appropriate to encourage junior staff to take responsibility at this level of security awareness. At the same time, it would be misguided to act as if this degree of analysis were sufficient. Doing so will deliver an environment consisting of some ad hoc combination of "steel doors and paper walls."

Security is an emergent property of the complete architecture of a site. You have to allow this thinking to influence every design decision, which is a pretty challenging requirement even for a senior system architect. To support that process, I think it's an extremely important perspective for us all to cultivate, to the degree that it makes sense within our own areas of specialization.

As far as I can determine, the most economical way to do that is to concentrate foremost on understanding and following reasonable security principles when building systems. It seems evident that this is not yet being done, even though there is good consensus, at elast among security experts, on what would be most useful to do.

[1] R. Evard, "An Analysis of UNIX System Configuration," Proc. LISA 1997 (Oct 1997)

[2] A. Whitten, "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0", USENIX Security Symposium 1999 (Aug 1999)

[3] J. Harker, "Developing a security policy," vnunet (Jan 2003)

The two previous postings in this thread both make excellent points. In common with both is the insight that security has to be addressed foremost in terms of design principles. The first posting discussed the principle of verifiability (the system keeps its word.) The second posting discussed consistency with respect to the requirements set by security policy.

It's not very productive to try to reason about the security of a system if we can't be certain how it was built, yet typically sites cannot say with certainty whether or not any of their hosts match a given definition of how they were to have been configured[1]. Similarly, the correspondence between policy and practice is ultimately a product of human effort, so that even with a clear and meaningful site policy in place, its effectiveness will tend to be adversely influenced by human factors [2]. Unfortunately it seems from some studies that only a very small minority of sites have developed security policies at all [3].

It's common for people at the outset to discuss security in terms of promoting a shopping list of specific security elements and practices. Indeed, it's probably appropriate to encourage junior staff to take responsibility at this level of security awareness. At the same time, it would be misguided to act as if this degree of analysis were sufficient. Doing so will deliver an environment consisting of some ad hoc combination of "steel doors and paper walls."

Security is an emergent property of the complete architecture of a site. You have to allow this thinking to influence every design decision, which is a pretty challenging requirement even for a senior system architect. To support that process, I think it's an extremely important perspective for us all to cultivate, to the degree that it makes sense within our own areas of specialization.

As far as I can determine, the most economical way to do that is to concentrate foremost on understanding and following reasonable security principles when building systems. It seems evident that this is not yet being done, even though there is good consensus, at elast among security experts, on what would be most useful to do.

[1] R. Evard, "An Analysis of UNIX System Configuration," Proc. LISA 1997 (Oct 1997)

[2] A. Whitten, "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0", USENIX Security Symposium 1999 (Aug 1999)

[3] J. Harker, "Developing a security policy," vnunet (Jan 2003)

Maybe because case-sensitivity is a stupid carry-on from UNIX filesystems. How the hell do you explain to a new user that the files 'MyFile', 'MYFile', 'MYFILE', 'myfile' and 'myFile' are all different files? What OS X does is case-preservation without case-sensitivity, so you can save as 'myFile' for example, but all other combinations such as 'MyFIlE' refer to that file. It makes more sense, and I've been a UNIX user for 15 years.

By the way, this does knacker up LWP-Perl which insists on having a /usr/bin/HEAD command that screws around with /usr/bin/head, which I think goes to prove my point. Why should a system have two differently operating commands that have the same name and location and only differ in case? It's completely braindead.

Of course, if you need it for UNIX development, you can make a UFS disk image in Disk Copy, mount it and work on your code in that Volume which will be completely case-sensitive.

Wilfredo Sanchez of Apple wrote a paper on this and other HFS+ vs UFS issues for USENIX, and you can read it here.

Take a look at http://www.fs.net ... There was an article in the ;login Dec 2002 issue

"SFS is a secure, global network file system with completely decentralized control. SFS lets you access your files from anywhere and share them with anyone, anywhere."

I have no idea what the poster is talking about. SAGE has never been at a "trade show," to my knowledge (other than exhibit floors of the occassional conference with which we have co-sponsorship agreements). We run our own annual technical conference, LISA. I honestly can't imagine what we'd do at a trade show. We don't have anything to sell--we're a nonprofit, membership organization dedicated to advancing the profession of system administration.

I think I'll just ignore the rest of the poster's comment. Perhaps the poster is confusing SAGE with some other entity.

Trey Harris
Vice President, SAGE

What you are asking for cannot be done. Worse, it is a dangerous route to go down, because it gives an illusion of safety.

From a VM level you cannot know what a program it up to unless that program obeys certain rules. When dealing with x86 architecture (specifically), those rules are not sufficiently verbose to allow for the sort of checking you are after.

While a VM could intercept all stack access and prevent modification to the return address (presenting stack smashing attacks), it cannot tell if a malicious attack has caused values within a valid range in the stack or heap to be altered in a way that is not supposed to happen. Thus a VM approach would suffer all of the deficiencies of StackGuard.

So while you may be able to protect against a classic buffer overflow attack (overwrite the return address on the stack and jump to your own code), there is no guarantee against arbitrary modification of the behaviour of the software by adjusting variables.

The dangerous part is that you are trying to partition security and look at one aspect of it in isolation. This is shortsighted.

Using permissions, a binary running in a user acocunt is less of a threat to overall system security than a binary running as root -- irrespective of whether there are exploitable vulnerabilities in that binary or not.

Tools like the ptrace-derived sandbox further improve this situation -- an arbitrary binary could be denied access to the file and IO functions in the kernel, preventing a malicious intruder from reading or modifying the hard drive. Or those open function could be filtered by directory. Network access could be restricted, denying the opportunity of using the vulnerability as a springboard to probe behind a firewall.

There is an interesting Usenix paper relating to these issues. There is a list of sandbox possibilities plus another one here, and you should also check out Medusa. this article also points to several resources on ACLs.

Read MS licensing 6.0 in regards to T.C.O. The gartner group did some research as well a couple years ago into this TCO area.

It has been known for awhile that Microsoft speeds up IE by ignoring handshakes between IE and IIS when connecting. This breaks a standard and makes it appear faster.

Similiarly one of the reasons why people falsely think Mysql is faster then postgreSQL is because Mysql does not support transactions. You can use pure inserts to make it appear faster but corrution can occure. Is com+ doing the same thing?

A simple benchmark shows one thing but not the whole picture. Just like the database argument above thorough benchmark shows actually postgreSQL ahead when large loads are counted in. Can com+ handle large loads? Thread benchmarking shows that Unix has alot more performance since it can scale and handle synchronization.

Does it run in the kernel like IIS and parts of the sql-server engine? Microsoft's own halloween documents stated that IIS was faster because its in the kernel. This brings down stability.

I am not an expert but quality and reliabilty have not been Microsoft's strong points in its history. This is why I would feel more comfortable buying a more expensive solaris box then a win2k box with a proprietary com+ apps that can not be ported.

Future versions may not be stable and vendor lock in comes into play. Microsoft just recently came out with new patches for IIS and sql-server but could not guarauntee the relibity of the patches. Its getting r00ted or putting up with frozen servers.

There really is a SFU; it is a subsystem, and these people are using it. But you can't use a subsystem by itself; a subsystem is useful only as part of a whole operating system. SFU now inludes Interix which is normally used in a combination with the GNU development toolchain and libraries : the system is basically GNU, with SFU functioning as the compatibility DDL Library layer.

Many users are not fully aware of the distinction between the compiler toolset, which is SFU, and the whole system, which they also call `SFU''. The ambiguous use of the name doesn't promote understanding.

Programmers generally know that is a Subsystem. But since they have generally heard the whole system called `Interix' as well, they often envisage a history which fits that name. For example, many believe that once Softway Systems finished writing the posix compatibility DDL Libraries, they looked around for other free software, and for no particular reason most everything necessary to port a Unix-like system was already available.

What they found was no accident--it was the GNU system. The available free software added up to a complete system because the GNU Project had been working since 1984 to make one. The GNU Manifesto had set forth the goal of developing a free Unix-like system, called GNU. The Initial Announcement of the GNU Project also outlines some of the original plans for the GNU system. By the time Interix was written, the system was almost finished.

Most software projects have the goal of developing a particular program for a particular job. For example, Softway Systems set out to build an environment to allow UNIX apps to be ported directly to NT. Donald Knuth set out to write a text formatter (TeX); Bob Scheifler set out to develop a window system (X Windows). It's natural to measure the contribution of this kind of project by specific programs that came from the project.

If we tried to measure the GNU Project's contribution in this way, what would we conclude? If you had access to the full source code of SFU with Interix, you might find found that, GNU software was the largest single contingent, around 60% of the total source code, and this included some of the essential major components without which there could be no compatable subsystem. SFU by without Interix itself could be about 20%. So if you were going to pick a name for the system based on who wrote the programs in the system, the most appropriate single choice would be `GNU''.

But we don't think that is the right way to consider the question. The GNU Project was not, is not, a project to develop specific software packages. It was not a project to develop a C compiler, although we did. It was not a project to develop a text editor, although we developed one. The GNU Project's aim was to develop a complete free Unix-like system: GNU.

Many people have made major contributions to the free software in the system, and they all deserve credit. But the reason it is a system--and not just a collection of useful programs--is because the GNU Project set out to make it one. We made a list of the programs needed to make a complete free system, and we systematically found, wrote, or found people to write everything on the list. We wrote essential but unexciting major components, such as the assembler and linker, because you can't have a system without them. A complete system needs more than

I read this article a few days ago and bookmarked most of the links I thought valueable. If anyone else is interested add some more to this thread so I can grab them :)

Exported bookmarks Fingerprint
blackhole(4) - a sysctl(8) MIB for manipulating TCP
Help Net Security OS-FngrPrint article in PDF
Honeyd - Network Rhapsody for You
http://ojnk.sourceforge.net/stuff/iplog.readme
http://www.insecure.org/nmap/nmap-fingerprinting-a rticle.txt
IP Personality - Home
Kernel Options
p0f file listing
PhoneBoys FireWall-1 FAQs: Blocking queSO packets
s0ftpr0ject 2000 Fingerprint Fucker
Security Technologies
SourceForge.net: Project Info - SING
Sys-Security.com - Because Security is not Trivial
USENIX Technical Program - Abstract - Security Symposium - 2000

> and a new Windows operating system at Version1.0 quality

Actually, if you look at the Windows source (from Windows 2000 on), you'll see that most of it is #ifdefs, not a lot of new code. There was a 64-bit transition guide available before Windows 2000 launched. In fact, according to this presentation, they did 56 IA-64 builds a week during the Win2000 development cycle alone. MS has had 3+ years since then to prepare for 64-bit, including Opteron. So most of your points sound a bit silly to me -- if this is v1.0 quality, then so is Linux for the Opteron. The only thing with NT/64bit is that it's been available mostly through special-order and not at dell.com.

And a small point -- there's no *technical* reason NT can't be ported to all sorts of architectures. In fact, given that you basically have to port the HAL (and recompile the rest), new architectures can be added pretty easily.

• Joining your local student ACM chapter. Better yet, run for office - I know they need the person power. If it doesn't exist, charter it!
• Want to attend a technical conference? Both USENIX and the IETF have programs designed to get students involved by providing stipends. Often, these programs are applied to by few students.
• If you prefer getting involved with a .com than a .org, consider that Apple gives away about 300 scholarships to their annual develpers conference in San Jose, WWDC.
• If you are an uber programmer, perhaps you should try registering as a student or evan as a competitor or presenter at MacHack.
• The Government is always hiring, and don't let anyone tell you that you have to get a security clearance to work on something cool.
• An earlier posted mentioned that the University IT department is a good place to work, and for the most part I agree - there are few other places with the budget and deployed network size of Univsersities that will teach you as you go.

Tcl runs the operator interface of Shell Oil's Auger, a drilling rig in the Gulf of Mexico. See pictures of the rig here, and read about the system integrators here.

Don't like oil rigs? Well, it's highly unlikely that you can mod this post down without the Tcl that's built into practically every Cisco router on the planet. Read Cisco's tesimonial.

Once you've done that, go log off and watch TV. Oh yeah, did you know that the NBC network control system is a Tcl application? It is; it's been in the digital broadcast system from prototype all the way to full 24x7 operation. ComputerWorld ran an article about the project.

Science geeks will be interested that a Tcl interface is used to program the Hubble Space Telescope

Database heavies will be intrigued by the intimate role that Tcl has in Oracle Enterprise Manager.

I could go on all evening, this is just the tip of the proverbial iceberg.

Tcl runs the operator interface of Shell Oil's Auger, a drilling rig in the Gulf of Mexico. See pictures of the rig here, and read about the system integrators here.

Don't like oil rigs? Well, it's highly unlikely that you can mod this post down without the Tcl that's built into practically every Cisco router on the planet. Read Cisco's tesimonial.

Once you've done that, go log off and watch TV. Oh yeah, did you know that the NBC network control system is a Tcl application? It is; it's been in the digital broadcast system from prototype all the way to full 24x7 operation. ComputerWorld ran an article about the project.

Science geeks will be interested that a Tcl interface is used to program the Hubble Space Telescope

Database heavies will be intrigued by the intimate role that Tcl has in Oracle Enterprise Manager.

I could go on all evening, this is just the tip of the proverbial iceberg.

read something a little more descriptive of the winblows development process. Mark Lucovsky wrote this ppt presentation to share with the world why windows has "issues". paul's junk looks like its ready to go into third grade readers and whatnot. though i do like the colorful metaphors like "bowels of microsoft".

Since you can now run bash and other unix-y things on Macs, I've noticed there have been a lot more people at the 2002 LISA conference with Mac laptops than PC laptops. At the 2000 LISA conference, most people had Sony Vaios.

Anyone remember AudioFile? It was an audio server whose architecture was roughly similar to X.

Get a copy of _The Practice of System and Network Administration_ by Thomas A. Limoncelli and Christine Hogan. Read chapter 15 (Help Desks) and implement it faithfully. For real-world system and network administration topics, this is the best book I've run across. There's a FreshMeat review available.

There's also a website at www.sysadminfocus.com, but get a dead-tree copy as there's not much on the website.

Then, get involved in SAGE and USENIX. These are common problems, and talking about them with a body of folks who know how to solve them is going to much more productive than posting to Slashdot ;-)

>I know it sounds trivial and off topic but I'm serious. Check your
>resume.

Best resume advice I've seen: http://www.usenix.org/publications/login/2000-7/fe atures/resume.html

Nope. A magnetic field that would be strong enough to erase a hard drive would probably also compress it into a lump of twisted metal. from http://www.usenix.org/publications/library/proceed ings/sec96/full_papers/gutmann/:

US Government guidelines class tapes of 350 Oe coercivity or less as low-energy or Class I tapes and tapes of 350-750 Oe coercivity as high-energy or Class II tapes. Degaussers are available for both types of tapes. Tapes of over 750 Oe coercivity are referred to as Class III, with no known degaussers capable of fully erasing them being known [19], since even the most powerful commercial AC degausser cannot generate the recommended 7,500 Oe needed for full erasure of a typical DAT tape currently used for data backups.

Degaussing of disk media is somewhat more difficult - even older hard disks generally have a coercivity equivalent to Class III tapes, making them fairly difficult to erase at the outset. Since manufacturers rate their degaussers in peak gauss and measure the field at a certain orientation which may not be correct for the type of medium being erased, and since degaussers tend to be rated by whether they erase sufficiently for clean rerecording rather than whether they make the information impossible to recover, it may be necessary to resort to physical destruction of the media to completely sanitise it (in fact since degaussing destroys the sync bytes, ID fields, error correction information, and other paraphernalia needed to identify sectors on the media, thus rendering the drive unusable, it makes the degaussing process mostly equivalent to physical destruction). In addition, like physical destruction, it requires highly specialised equipment which is expensive and difficult to obtain (one example of an adequate degausser was the 2.5 MW Navy research magnet used by a former Pentagon site manager to degauss a 14" hard drive for 1 minutes. It bent the platters on the drive and probably succeeded in erasing it beyond the capabilities of any data recovery attempts [20]).

Isn't this kind of ideology exactly what let to the 'dot-com crash'. People invested lots of capital in companies that people enjoyed but weren't necessarily very profitable. I think google is the latest subject to this phenomenon. Although I could be,and hope that I am, wrong.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

Isn't this kind of ideology exactly what let to the 'dot-com crash'. People invested lots of capital in companies that people enjoyed but weren't necessarily very profitable. I think google is the latest subject to this phenomenon. Although I could be,and hope that I am, wrong.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

Incidentally, for those 5 years, NBC has been using Tcl in mission critical, real time applications to stream video to affiliates across the country.

I've been using tDOM lately, a Tcl interface to the DOM. It is, quite simply, the fastest XML parser I have found.

a sysadmin has to be ethical.

I imagine that's why the System Administrators Guild has a SysAdmin Code of Ethics.

Hmm. I wonder if BOFH's also have their own code of ethics too?

Jim Truher from Microsoft had an informal Birds-Of-a-Feather session at LISA 2002. I showed up because I wanted to see this guy squirm a little (LISA is almost all UNIX/Linux folk). He claimed to be one of the designers of this new shell and he wanted our input about the most needed features. He mentioned created a language similar to PERL only better(i.e. proprietary). Full transaction support was suggested as well to allow a multilevel "undo" capability.

FYI.. .I was at the USENIX/SAGE L.I.S.A Confrence 2002 in Philly a few weeks ago, and some guys from Microsoft had a late night get together to talk to us unix people. I couldn't not go, after all it was Microsoft at a 100% NIX-only event, so I figured some fun would be had at their expense.. It was called: UNIX + Windows Admin Management with Scripting & Command Line: What are your requirements?, and was on thursday night. The point of the meeting is that, they wanted to know from UNIX admins what makes a good Command Line environment and what it would take to make Windows have as powerfull a CLI as Unix. They pretty much told us that there is a LARGE high-level project at Microsoft to make Windows servers to be as easy to manage and configure as Unix servers from a serial port with no gui required. What is their REAL goal: From what I could tell its simple... they want to eliminate the competitive advantage that UNIX has with the CLI. That this away from NIX as a "advantage", then thats one less think people can point to as something that Windows lacks. They want to be able to honsetly say... "Unix isnt any easier/more-powerful on the CLI than Windows." After all, that is one of the SINGLE LARGEST differences there are today between their product and NIX. Take that argument away, and you have a huge marketing/argument weapon against us NIX people.

FYI.. .I was at the USENIX/SAGE L.I.S.A Confrence 2002 in Philly a few weeks ago, and some guys from Microsoft had a late night get together to talk to us unix people. I couldn't not go, after all it was Microsoft at a 100% NIX-only event, so I figured some fun would be had at their expense.. It was called: UNIX + Windows Admin Management with Scripting & Command Line: What are your requirements?, and was on thursday night. The point of the meeting is that, they wanted to know from UNIX admins what makes a good Command Line environment and what it would take to make Windows have as powerfull a CLI as Unix. They pretty much told us that there is a LARGE high-level project at Microsoft to make Windows servers to be as easy to manage and configure as Unix servers from a serial port with no gui required. What is their REAL goal: From what I could tell its simple... they want to eliminate the competitive advantage that UNIX has with the CLI. That this away from NIX as a "advantage", then thats one less think people can point to as something that Windows lacks. They want to be able to honsetly say... "Unix isnt any easier/more-powerful on the CLI than Windows." After all, that is one of the SINGLE LARGEST differences there are today between their product and NIX. Take that argument away, and you have a huge marketing/argument weapon against us NIX people.

Hope also that FreeBSD will soon enough shoot for a journalled filesystem [...]

Security vulnerabilities are discovered, become publicly known, get exploited by attackers, and patches come out. When should one apply security patches? Patch too soon, and you may suffer from instability induced by bugs in the patches. Patch too late, and you get hacked by attackers exploiting the vulnerability. We explore the factors affecting when it is best to apply security patches, providing both mathematical models of the factors affecting when to patch, and collecting empirical data to give the model practical value. We conclude with a model that we hope will help provide a formal foundation for when the practitioner should apply security updates.

Also, the PDF seems to be broken. It won't display on my system. (Anyone else have that problem?)

Overall, pretty impressive.

The version on the USENIX site seems at least to have the correct spelling in the title, but you need a password to download the PDF there.

And while we may wonder where Microsoft stuck the UC Berkeley copyright notice in Windows, we're more likely to be aware that the internet works correctly because MS did use the BSD code base to start.


Right. It's great that they can take the code that the community wrote, and then give the community the shaft.

Look what Microsoft did with kerberos. They would not think twice about doing things (at the expense of everyone else) with TCP/IP if it furthered their marketshare.

I'm sorry, perhaps I'm missing something. Are you excited about the fact that ksycoca notifies applications about configuration changes while the application is running? That may be impressive if you come from Windows, but the X11 resource system has had that for a long time.

Have you ever even seen how X resources work? Have you seen tools like "editres" in action? With a compliant toolkit, you can click on an application, get its widget tree, change properties or event bindings on the fly, and save your changes. Of course, it doesn't work with Gnome or KDE, and there is nothing equivalent.

dcop is also not high bandwidth

Well, then standard X11 IPC mechanisms should be sufficient and DCOP is not needed, which is kind of my point.

I am pretty sure, that they gave a lot of thought to these issues

Yes, but that doesn't mean that they made the right decisions. KDE and Gnome were really written with a Windows-like frame of mind: a single, local display under full control of a single environment. I think the people who started working on it didn't even appreciate the hard problems that X11 and X11 toolkits were already addressing when those projects started. And while the KDE and Gnome codebases are a lot cleaner than Xaw and Motif, functionally, they have thrown us way back.

In fact, neither Gtk+ nor Qt are really X11 toolkits--they are Windows-like toolkits that happen to run on X11. Someone should probably take a new stab at creating a modern X11 toolkit from the ground up. See here for some related work: XCB, Gettys, Sharp.

I'm sorry, perhaps I'm missing something. Are you excited about the fact that ksycoca notifies applications about configuration changes while the application is running? That may be impressive if you come from Windows, but the X11 resource system has had that for a long time.

Have you ever even seen how X resources work? Have you seen tools like "editres" in action? With a compliant toolkit, you can click on an application, get its widget tree, change properties or event bindings on the fly, and save your changes. Of course, it doesn't work with Gnome or KDE, and there is nothing equivalent.

dcop is also not high bandwidth

Well, then standard X11 IPC mechanisms should be sufficient and DCOP is not needed, which is kind of my point.

I am pretty sure, that they gave a lot of thought to these issues

Yes, but that doesn't mean that they made the right decisions. KDE and Gnome were really written with a Windows-like frame of mind: a single, local display under full control of a single environment. I think the people who started working on it didn't even appreciate the hard problems that X11 and X11 toolkits were already addressing when those projects started. And while the KDE and Gnome codebases are a lot cleaner than Xaw and Motif, functionally, they have thrown us way back.

In fact, neither Gtk+ nor Qt are really X11 toolkits--they are Windows-like toolkits that happen to run on X11. Someone should probably take a new stab at creating a modern X11 toolkit from the ground up. See here for some related work: XCB, Gettys, Sharp.

pdf

Let's just say, they are well aware of the issues, and a lot of thinking and planning has gone into how they handle the load of major news events.

4. linux has a journaling filesystem, freebsd doesn't

Judge for yourself. Plan 9's Factotum security architecture was described in a paper presented at the USENIX Security '02 conference in August. The paper won the 'Best Paper' award, so it clearly impressed some people.

Much of this has to do with CS researchers forcing the conference publishers to allow distribution of papers via personal webpages. Once you have that, the rest follows.

But in fairness, Nature is only $160/year ($100 students), which covers 52 issues. Of course, you have to put up with advertising and pay a subscription...

• Many excellent formats have fizzled and died for far smaller reasons than that they intentionally eliminate your fair use rights.
• during that transition, neither side (the content people or the electronics people) can jump without the other (or they risk a zero-sales incident) and there are too many parties for everyone to jump at once.
• Any transitional period would have both formats available [I should point out in with roughly equal quantities of media], hence my point: consumers would have to choose, and as long as they have the choice, they won't choose DRM [because of the inconveniences it causes - even if there are "carrots" on the DRM side, the barrier to invest in new hardware is high, based on the cost of that hardware].
  

Here's an idea: make sure there's a benefit scheduled to coincide with LISA in Philly. I'll go!

Ole

PS. EFF, if you're listening -- get your damn secure site fixed -- the last time I tried to donate, the site barfed; I had to print out a page with my CC info filled in and fax it -- and I still never actually got billed.

OK, asshole. How about we start with Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems presented at USENIX 2000? The first three authors should need no introduction, so I think it satisfies the "well known" requirement; in fact, one could hardly find a group of six people more qualified to comment on the matter. Even in the abstract, the authors clearly state the similarity between goals of journaling and soft updates:

In this paper, we explore the two most commonly used approaches for improving the performance of meta-data operations and recovery

The similarity is mentioned repeatedly elsewhere in the paper, all the way to the conclusion, but I'll let you do your homework this time.

Anybody who knows anything about filesytems - and I've been working on them for over a decade - recognizes the similarity in goals between journaling, soft updates, and phase trees. Usually it's considered too obvious even to require comment, unless an ignorant troll like you comes along demanding that the obvious be spelled out.

I guess 640KB really is enough for anybody!

On slide 6 it states most development of NT was done on OS/2. I find that kinda interesting. Why didn't they use their own OS?

the later slides describe the NEW project resource management and development processes for the continuing development of Windows 2000 (before and up until after the release?)

Slides 23 and up tell you what they did and how well everything works on a project as large as Windows 2000 is.

This slide gives a sumary of the new build processes http://www.usenix.org/events/usenix-win2000/invite dtalks/lucovsky_html/sld033.htm

In contrast, USENIX is actual security technology. Take the tutorials for in-depth learning on important issues, and the technical sessions for cutting-edge practical security research. We have a paper this year on the LSM (Linux Security Modules) project.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

In contrast, USENIX is actual security technology. Take the tutorials for in-depth learning on important issues, and the technical sessions for cutting-edge practical security research. We have a paper this year on the LSM (Linux Security Modules) project.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase