Slashdot Mirror

No, I wasn't on the team, but I did read interviews with both Mark Lucovsky and Dave Cutler where they both mentioned this. The Wikipedia article is accurate.

http://www.winsupersite.com/reviews/winserver2k3_g old1.asp

"Finally, it was time to start writing some code. "We checked the first code pieces in around mid-December 1988," Lucovsky said, "and had a very basic system kind of booting on a simulator of the Intel i860 (which was codenamed "N-Ten") by January." In fact, this is where NT actually got its name, Lucovsky revealed, adding that the "new technology" moniker was added after the fact in a rare spurt of product marketing by the original NT team members."

And in case you don't trust Paul Thurrott, here's slides from one of Locovsky's presentations:

http://www.usenix.org/events/usenix-win2000/invite dtalks/lucovsky_html/tsld006.htm

Well, that you can recover data doesn't mean you can reliably recover it, or do it fast. Hence no 40TB drives.

As for how, the short version is that if you write a one and then a zero, you end up with .1; the old value leaks in a bit. When combined with the error correction codes built in to the drive, you stand a decent chance of recovering the overwritten data (slowly, with special read heads/drive electronics, and somewhat error prone). If you overwrite with the same fixed pattern repeatedly, you really don't improve the situation much (diminishing returns on removing the residual bit), so an 80x "wipe" of all zeros may be recoverable (although 80x is a bit much, even for all zeros). But overwriting to DoD spec is probably sufficient in this case, though. So is beating up the physical platters.

For the really determined attacker, then can use high resolution magnetic force microscopy (MFM). See, when you overwrite, the write head doesn't exactly line up with the old stuff--so you'll have little bits of the old data sticking out from above or below the track. MFM can resolve very localized magnetic fields, far smaller than your disk read head, and can see the misalignment. These misaligned pieces allow peaking back a few generations of overwrite, which allows you to subtract out the newer things (and hence clarify the older). Plus, it doesn't use rapidly spinning the disk, so it can work on beat up platters. Even without misalignment in the generations of overwrite, good MFM can resolve better analog detail as well, so the whole 1 then 0 = .1 thing works better. But it is far too expensive to bother with in most cases.

A detailed technical paper about the theory of data destruction/recovery on magnetic media can be found here: http://www.usenix.org/publications/library/proceed ings/sec96/full_papers/gutmann/

This sounds a bit like "Peep" the "Network Auralizer" released back in 2000. That used sound bites rather than machine generated music, but had a similar effect in that a SysAdmin could monitor multiple systems just by having the background sounds going.

I used it in a couple of places, and it worked relatively well - especially when the rest of the shop was quiet.

"I think GNU/Linux was there first...it just didn't have the marketing that Windows had." - by RAMMS+EIN (578166) on Sunday September 10, @09:53AM (#16075389)

Windows NT 3.x was there as well, around same time if NOT a year earlier iirc... see here:

http://www.usenix.org/events/usenix-win2000/invite dtalks/lucovsky_html/sld003.htm

Well, the statement "it was not possible to erase the data on them" directly contradicts the possibility of an answer the question of how to "non-destructively (physically) destroy data on a hard disk without access to a bulk eraser", unless of course, your current limitations include the magical exception of having access to some really fun electronics equipment.

Then again, I'm still wondering WTF the term "bulk eraser" is supposed to mean.

A useful starting point would be reading Secure Deletion of Data from Magnetic and Solid-State Memory. A quick Google search also came up with this tidbit concerning NTFS file systems.

http://research.microsoft.com/research/shield/pape rs/bshield.pdf

Also, this work will appear in OSDI (an operating systems conference) in November.

Much more Google techie info is on Rob Pike Usenix 04 talk: "Cheap Hardware + Fault Tolerance = Web Site" http://www.usenix.org/events/usenix04/tech/thurs.h tml

Did you know for example, that he says fancy cooling is only necessary, if your components are in a box. Wrap them to racks with velcro, drop the boxes, and you need no active cooling.

It does, indeed, depend upon the application. However, for password hashing, I would recommend bcrypt. OpenBSD implements this in its passwording scheme, and, on the Linux front, there's Openwall GNU/*/Linux. Solar Designer also has what might be needed for application implementation here: http://www.openwall.com/crypt/

Ross Anderson of the Computer Security Group at Cambridge University wrote a paper called the Eternity Service. It has had a few different attempts at implementation, as well as some reworks in terms of design. The primary difference is in the Eternity Service - you had no idea what data you had, nor did you have access to the keys. This new concept/design seems to provide more control/granualirity for the user. Given the new proposed encryption laws in the UK, I'm not sure this is a good idea.

Hard to see how this is possible? Then just read the paper here http://www.usenix.org/events/sec06/tech/shah/shah_ html/jbug-Usenix06.html and stop dismissing the idea on the basis of a secondhand report.

The delay between the user's key presses is irrelevant, the JitterBug will adjust the delay since the last key press so that, for example, the delay is a multiple of 20ms, or a multiple of 10ms but not 20ms. This gives you the "1" or "0" bits with 10ms separation for noise reduction and it doesn't depend on the user's typing speed, only on the value of delay modulo 20ms.

Given the delays you specify, I can easily imbed the message 1011 in your traffic. I do this by ensuring that every 1-bit in my message corresponds to an interval that ends in 5 and every 0-bit corresponds to an interval that ends in 0. So, given your input sequence (100,110,90,40), I delay the keystrokes to produce the sequence (105,110,95,45). This only requires that the network variance be less than 5ms.

I only skimmed the research paper, but this appears to be exactly what they propose as well. In particular, I think it's telling that they transmitted a secret message across the planet using their mechanism (using a 20ms window instead of the 5ms I used in my example).

Thought you might appreciate this article for some more possible detail...

http://www.usenix.org/events/sec06/tech/shah/shah_ html/index.html

I hate replying to myself, but the 1/7th of the data that you want to send would obviously be the next 20 characters or so after the ssh user@.* string. Sorry for not finishing the article before posting, but it's pretty damn long and boring. For those that feel like reading along, the usenix article that was posted earlier is at http://www.usenix.org/events/sec06/tech/shah/shah_ html/jbug-Usenix06.html

Pre-programming the logger with the username would also be a good method. Of course you could always switch to a different window (vi) and type some random stuff for a minute before going back to the ssh session if you suspected this problem. Or like everyone else has said, introduce your own jitter into the network traffic. I'd just hate to deal with that kind of throughput.

The best example of using this would be by the police that don't feel like reentering your home and placing the tap on your equipment and can get a sniffer right at the ISP with minimum network lag. Beyond that, I think people are being paranoid. But then, that's what slashdot is here for.

OK, thanks to someone else for digging up the real paper. It's actually quite interesting how they do it, and it makes sense. I encourage anyone who is interested to just avoid the article that was posted and read the paper instead. Much more intellectually satisfying...

I just get worked up by how much the press tries to fear monger these days and, given the increbile lack of detail there, assumed it was overblown. After reading the real paper, I have to admit that I was wrong.

Here is the paper.
A "Keyboards and Covert Channels" search on Google will give you the PDF, too.
I don't have time to read it right now (time to sleep here in France ;) so if someone want to read and report his conclusion that I can read next morning...

I don't know about the source, but you can get the paper right here. It has a little more details than the article.

I might guess that most USENIX, SAGE and LOPSA members are well versed in open source tools.

You could try the respective jobs boards:

• http://www.usenix.org/jobs/
• http://www.sage.org/jobs/
• http://lopsa.org/jobs

I might guess that most USENIX, SAGE and LOPSA members are well versed in open source tools.

You could try the respective jobs boards:

• http://www.usenix.org/jobs/
• http://www.sage.org/jobs/
• http://lopsa.org/jobs

I might guess that most USENIX, SAGE and LOPSA members are well versed in open source tools.

You could try the respective jobs boards:

• http://www.usenix.org/jobs/
• http://www.sage.org/jobs/
• http://lopsa.org/jobs

reliability of SCSI versus ATA is largely imagined and the rest is intentional. drive manufacturers want you to believe their enterprise drives are more reliable and right now those drives are largely SCSI.

Yeah, seriously, "League of Professional System Administrators" Are they a superheroes, a group of sports teams, WTF!? Contray to what LOPSA says SAGE is not dead. In fact, anyone that's been around long enough remebers that when SAGE became a part of USENIX in 1992 it was a win-win for both SAGE and USENIX. You get better benefits, more members and a common purpose in promoting and using *NIX. Why mess with a good thing?

I'll second this recommendation for LISA. The tutorials are a good way to get a base understanding of a specific topic. (The tutorial schedule for LISA'06 is not yet announced.) Check out other USENIX events as well, http://www.usenix.org/events/

While I've never personally paid to attend a USENIX conference, my employer has paid for me to attend several.

The 20th annual USENIX LISA System Administration conference is in Washington DC in December. Lots of content, no fluff.
http://www.usenix.org/events/lisa06/
Disclaimer: I teach tutorials at USENIX conferences, but I've paid to attend many over the years

The 20th annual USENIX LISA System Administration conference is in Washington DC in December. Lots of content, no fluff.
http://www.usenix.org/events/lisa06/
Disclaimer: I teach tutorials at USENIX conferences, but I've paid to attend many over the years

however, it's easier conceptually to write a threaded server, it's more natural to write, and you just launch a single thread per connection. unfortunately, currently, this doesn't scale (see Why Events Are A Bad Idea (for High-concurrency Servers) http://www.usenix.org/events/hotos03/tech/vonbehre n.html for an argument that thread implementations, and not their design, are the issue).

the former method can handle thousands of simultaneous connections with high throughput, even on a decent workstation; the latter cannot. threads simply have an inherent overhead that cannot be eliminated.

i've actually been working on writing a non-portable insanely fast httpd in my spare time (svn co svn://parseerror.dyndns.org/web/) over the past few weeks as a way to explore non-blocking I/O + epoll() and it performs very well (~600% faster conns/sec than a traditional fork()ing server (which i wrote first)).

for further discussion see The C10K Problem http://www.kegel.com/c10k.html which goes in-depth on these very subjects

There were some motherboard BIOSes that had built in boot sector virus scanning, but they didn't know anything about Free operating systems. A BIOS watchdog wouldn't be any better, most likely. The other problem with virtualization is that it does cause a slight overhead for any protected mode instructions that need to be virtualized. It doesn't help that the x386 architecture has several unprivileged instructions that can easily tell an OS whether it's being emulated or not (see this paper). Timing privileged instructions will also allow a hosted operating system to detect virtualization unless the entire system is emulated, which is very slow.

Reading from "AGP memory" is uncached & slow, but not that slow. Readback from the GPU's local texture memory across the AGP port is what's really slow, because it's effectively a 33 MHz PCI bus in that direction. Though even that isn't anything like as slow as 16MB/s (once GPU vendors bothered to optimise that driver path at least).

Yes, it really is that slow. See this article from a DRI developer: DRI article. Also, remember the hit for uncached accesses for an in-order CPU like Cell or Xenon is even larger. An out-of-order CPU can keep working after issuing a read, up to the depth of its load buffer. That means it may be able to transfer 32 words (depending on the size of the load buffer) very 500 cycles (or however long the memory latency is). An in-order CPU cannot do even that, and must wait the whole memory latency after every load.

Try 1.8 TFLOPS [wikipedia.org] vs 150 GFLOPS. Cell is great for doing vector crunching of physics transformations, but RSX has way more vector hardware (think 48 pipes instead of 7, plus assorted bilinear interpolation units at each end, comparison units etc etc). This is offset by RSX's lower clock and less-optimal architecture, but the GPU is still a very powerful cruncher.

Of course, that's why I said "general pupose" gigaflops. The GPU has a lot of its "1.8 teraflops" tied up in non-reprogrammable special-purpose hardware. Each of the 24 pixel shaders and 8 vertex shaders have a pair of 128-bit FPUs. That gives it a 128 gigaflops peak throughput. The rest of the "1.8 teraflops" is tied up in things like interpolators that compute per-pixel parameters like texture coordinates across the triangle. These units are not full FPUs (thus they aren't really a general purpose FLOP), and in any case cannot be retasked to do things like running physics code. That's why things like GPGPU get only 60 usable gigaflops from a top of the line ATI graphics card that's rated at 1+ teraflops.

It's there for a reason.

My flame:

"I'm sure you'll get a lot of these messages, but hell, you deserve it.

The slow read speed you noted in the slide is for Cell reading from the RSX's local memory. Such accesses are expected to be very slow. If you look at this USENIX article from one of the Linux DRI folks, you can see this quite easily:

DRI article

He shows how painfully slow it is to read from AGP or framebuffer memory (14 and 5 MB/sec, respectively), on a Rage 128 graphics card. For the CPU to framebuffer read, which is the equivalent to what we're talking about here, the read speed is 1/40th the write speed. At 16MB/sec read and 4GB/sec write, the PS3 is actually right in line with what can be expected of modern GPU architectures.

Reading from the framebuffer is just slow unless you have a unified memory architecture. The CPU and the GPU aren't cache-coherent, which means every access to framebuffer memory (or even AGP memory, which is actually a chunk of system memory allocated to the GPU) must be an uncached access. Uncached accesses are just plain slow, on any architecture.

The way your article is written, it makes it seem like Cell reads its local storage at 16 MB/sec. That is, of course, bollocks, since IBM has shown benchmarks of the Cell local storage achieving 98% efficiency. If you had any journalistic integrity at all, you'd post a retraction on your site, and a clarification of the technical issues involved."

Some people here still expect beta to mean beta, which is conventionally intended to identify bugs in an otherwise stable product. A beta release is not, as you suggest, an invitation to change the feature set, though that has never prevented Microsoft from bending the rules at its convenience.

To be charitable, I can imagine that with this Vista beta, the codebase might indeed be as stable as what we ordinarily expect from a beta release, and so what we're looking at now is just a matter of tuning the configuration parameters so that it prompts at the right thresholds. And, on the principle of security by default, the system will initially tend toward maximum prompting. However, thinking more soberly, a secure system will have fully addressed these issues at the design level, and prompting will not be excessive but appropriate and meaningful. If it's not, that's a clear sign that the design has deeper problems than can be fixed just by changing the prompting parameters. Pardon my cynicism, but in my experience, that would be entirely typical of Microsoft.

Definition of beta at: Wikipedia.

For usability see: Whitten and Tygar.

I'd say one of the first questions you need to ask yourself (and your management and legal people) is what level of security you require for your data. After that read up on NFSv3 security; a good article is at http://www.usenix.org/publications/login/2005-02/p dfs/musings.pdf , which touches on most of the major problems. And yes, the situation really is that bad, and tools to exploit the numerous weaknesses are easily obtainable. NFSv3 "security" is a joke. Unless you use it purely as a back end system on a secured, private network between physically secure machines that only people who have access rights to all files on the server have access to, you will lose to any minimally skilled cracker or disgruntled employee (or if someone decides to write self-replicating malware that exploits NFSv3 weaknessess, which frankly I wish someone would do so management types could fully grok how exposed they are).

Once your company understands how unacceptable NFSv3 security is for any kind of situation involving company-confidential or legally-sensitive data, solutions like Network Appliance will start to look like they suck, because they do not support any decently secure protocol that the majority of Unix clients can use, nor will they unless the vendor feels like adding them (appliance model = big, useless / overpriced bricks if you change storage strategies). Only the very latest Unix versions support NFSv4 at all, and that support is universally not well documented, and in my experiance, esp. on GNU/Linux, somewhat buggy. Managing the differing permissions models between CIFS, NFSv3 and NFSv4 is also insanely complex, with lot of subtle problems that can leave you wide open.

There is exactly one non-kludgey widely used solution to this problem, and that is OpenAFS (http://www.openafs.org). Designed for security, proven over more than a decade in demanding environments (Morgan Stanley, MIT, CMU), same permissions model across platforms etc. If you'd like to talk to a vendor, Sine Nomine Associates (http://sinenomine.net/support/afs) is one of several that sell support contracts (the software itself is Open Source). The best vendor backup solution for OpenAFS is TiBS (http://www.teradactyl.com/Products/Afs.html), although roll-your-own is pretty easy as well. Note that if you don't want to touch the Windows desktops with OpenAFS client installs, Samba has excellent support for using OpenAFS as a back end (i.e. Windows clients accessing AFS-space via their native CIFS clients via Samba). There is also a NFSv3 translator service for if you happen to have any extremely odd or old Unix operating systems that aren't supported by OpenAFS or ARLA
(http://www.stacken.kth.se/project/arla/) clients. Another option in some cases would be to buy Sharity (http://www.obdev.at/products/sharity/index.html) licenses and access AFS-space via CIFS/Samba. To use OpenAFS you also need a Kerberos 5 KDC; for this you can use Active Directory, or MIT or Heimdal Kerberos 5, which are both free. For a cross-platform single signon solution, you can combine Samba, OpenLDAP and Heimdal; this requires experianced unix-y sys admins, but companies like Symas Corp., http://www.symas.com/ , will do it for you.

You mentioned DCE/DFS (which I've noticed several people have misinterpreted as Microsoft dfs, which has almost nothing in common with DCE/DFS). DCE/DFS is dead. It had little vendor uptake; IBM supplied clients for most platforms, and IBM stopped development and ended support quite a while ago. Management was a complete nightmare. There is no open source implementation. It's dead, Jim! :-)

IBM has 2 major migration paths away from DCE/DFS (and IBM AFS, which is also end-of-lifed, although most of those customers just moved to OpenAFS). One is SANFS (http://www.redbooks.ibm.com/abstracts/SG247057.ht ml?Open), which is cool but appropriate to only a limited r

Let's ask Apple what thinks about all this: "Advanced Synchronization in Mac OS X: Extending Unix to SMP and Real-Time":

"xnu is not a traditional microkernel as its Mach heritage might imply. Over the years various people have tried methods of speeding up microkernels, including collocation (MkLinux), and optimized messaging mechanisms (L4)[microperf]. Since Mac OS X was not intended to work as a multi-server, and a crash of a BSD server was equivalent to a system crash from a user perspective the advantages of protecting Mach from BSD were negligible. Rather than simple collocation, message passing was short circuited by having BSD directly call Mach functions. While the abstractions are maintained within the kernel at source level, the kernel is in fact monolithic. xnu exports both Mach 3.0 and BSD interfaces for userland applications to use. Use of the Mach interface is discouraged except for IPC, and if it is necessary to use a Mach API it should most likely be used indirectly through a system provided wrapper API."

Its not like softupdates are a superior solution to the same problem or anything.

This is a troll. "Background FSCK" isn't BSD's answer to journaling. Soft updates is Dr. McKusick's implementation to maintain filesystem integrity in the event of a system failure. BSD doesn't need journaling, it has soft udpates. You need to read:

http://www.usenix.org/publications/library/proceed ings/usenix2000/general/seltzer.html

http://www.mckusick.com/softdep/

Do you actually want people to take you seriously when you post utter shit like this?

Fact: Mach performs poorly due to message passing overhead. L3, L4, hybridized kernels (NT executive, XNU), K42, etc, do not.

That is a veiled lie. Mach performed very poorly mostly because of message _validation_, not message passing (although it was pretty slow at that too). I.e. it spent alot of cycles making sure messages were correct. L3/L4 and K42 simple dont do any validation, they leave it up to the user code. In other words once you put back the validation in userland that Mach had in kernelspace, things are a bit more even. And for the love of god NT is NOT a microkernel. It never was a microkernel. And stop using the term "hybrid", all hybrid means is that the marketing dept. wanted people to think it was a microkernel...

Now I will throw a few "facts" at you. It is possible with alot of clever trickery to simulate message passing using zero-copy shared memory (this is what L3/L4/K42/QNX/etc... any microkernel wanting to do message passing quickly). And if done correctly it CAN perform in the same league as monolithic code for many things where the paradigm is a good fit. But there are ALWAYS situations where it is going to be desirable for seperate parts of an OS to directly touch the same memory in a cooperative manner, and when this is the case a microkernel just gets in your damn way...

Fact: OpenBSD (monolithic kernel) performs worse than MacOS X (microkernel) on comparable hardware! Go download lmbench and do some testing of the VFS layer.

Ok... Two things. OpenBSD is pretty much the slowest of all BSD derivitives (which is fine, those guys are more concerned with other aspects of the system and its users are as well), so using it in this comparison shows an obvious bias on your part... Secondly, and please listen very closely because this bullshit needs to stop already, !!OSX IS NOT A MICROKERNEL!! It is a monolithic kernel. Yes it is based on Mach, just like mkLinux was (which also was not a microkernel). Lets get something straight here, being based on Mach doesnt make your kernel a microkernel, it just makes it slow. If you compile away the message passing and implement your drivers in kernel space, then you DO NOT have a microkernel anymore.

So what you actually said in your post could be re-written like this:

Fact: OSX is sooooo slow that the only thing it is faster than is OpenBSD. And you cant even blame its slowness on it being a microkernel. How pathetic... Wow, that says it all in my book :)

And no, you dont have to believe me... Please read this before bothering to reply.

http://www.usenix.org/publications/library/proceed ings/javavm02/full_papers/jacob/jacob_html/node12. html

http://www.shudo.net/jit/perf/

IBM's VM looks very favorable in these tests. You can get it for Linux (also available for windows and other platforms) here:

http://www-128.ibm.com/developerworks/java/jdk/lin ux/download.html

Enjoy!

Taft

The fact that they had to shut down the site for updates is an indication that they haven't solved the (difficult) problem of performing live software and hardware updates. This looks to me like a fundamental design constraint of their solution, rather than a bug that can be addressed in a beta-testing cycle. Other internet-based service providers, like Google, Akamai, and (to a limited extend) Wikipedia, addressed this problem from day one. (Wikipedia reverts to a static browsing mode during some update operations.)

As I said, the reliable operation of a service is a difficult problem. At the Second Workshop on Real, Large Distributed Systems (WORLDS '05) Mike Afergan and his colleagues presented a very interesting paper detailing the design methodology used to achieve commercial-quality reliability in the Akamai content delivery network. As they write in the abstract, the Akamai network consists of 15,000+ servers in 1,100+ networks and spans 65+ countries. The paper makes very interesting reading.

--
Code Quality: The Open Source Perspective(Addison-Wesley 2006)

Tcp/ip stack (i'm assuming you're thinking about the implementation) is NOT the same as the tcp ip protocol. They do NOT change tcp,udp, ip (v4/v6), they finally just figured out that it's time to conform to standards. Let's look at that link of yours and see what it says:

1: Dual IP layer architecture for IPv6
Well what i can make out of all this mumbojumbo is that MS will support ipv6. Nothing more. Thats the point of encapsulation, it was ALWAYS intended to work that way.

2: Easier kernel mode network programming
The new API, wonder if it will be backwardscompatible, it probably will since just too many applications will break if it isn't.

3: Routing compartments
wow, each interface with it's own routing table, how... original...

4: Support for a strong host model
Seems nice in SOME circumstances, however will it be optional?

5: New security and packet filtering APIs
Wow is this for real? They made a firewall, wow! i'm impressed!

6: New mechanisms for protocol stack offload
http://www.usenix.org/events/hotos03/tech/full_pap ers/mogul/mogul.pdf (PDF)
Not big, just shows WHY this is a bad idea....

7: New support for scaling on multi-processor computers
Cool, they finally got their underlying network to support smp! (Why is another question though, won't be much use in most circumstances)

8: "New extensibility
The Next-Generation TCP/IP stack has an infrastructure to enable more modular components that can be dynamically inserted and removed."
As i mentioned, tcp/ip is based on capsulation techniques, which imply modular components :)

9: Reconfigure without having to restart the computer
No really? FINALLY! I'm impressed, NOONE has ever done that, you should get a patent...

10: "Automatic configuration of stack settings based on different network environments" ... Why weren't we able to do that in win95 again?

11: Supportability enhancements
No way to tell what this will be, guess some more statistics/errormsgs

As for the improvements they claim, well it's actually a SHAME that they haven'
t done this YEARS ago, ALL improvements here are nothing but catching up to the rest of the OS-world...

So no, do not be afraid, this is nothing new... it's only ms trying to catch up with the rest. They still lack a few decades of experience though....

The clock sold for 750. AUD The book, signed by various people, sold for 10,000 AUD and there was a considerable amount of money simply donated "out of pocket". ALL of that money will be doubled by USENIX, and given to the University of New South Wales to help create a position for a professor who will teach computer science in honor of John Lions.

Make no mistake about the fact that ALL of the money paid for the license plate off my wrangler will be doubled by USENIX and also given for the same cause.

If any other person would like to donate money to this cause, they can do this at:

http://www.cse.unsw.edu.au/JohnLions/

or

http://www.usenix.org/about/lionsfund/index.html

Regards,

maddog

Eddie Kohler, whose PhD thesis at MIT was the Click modular router (which from what I understand turned into the "engine" behind XORP), is one of the principal designers and developers of XORP. They published a paper at NSDI last year, which you can read here (Warning: PDF). It states very clearly what the goal of XORP is, and how well it performs. Quite interesting.

Well, I would say the salary survey is the least important thing they do, but if you are concerned with system administration as a profession, ethics, or training, I would say SAGE & USENIX are the two most important organizations available. And it's $155 a year if you want any more than the survey, plus fees for the conference, so it sounds like you really have not seen the real benefits. Try LISA, you will not be disappointed. (;login is good also)

Well, I would say the salary survey is the least important thing they do, but if you are concerned with system administration as a profession, ethics, or training, I would say SAGE & USENIX are the two most important organizations available. And it's $155 a year if you want any more than the survey, plus fees for the conference, so it sounds like you really have not seen the real benefits. Try LISA, you will not be disappointed. (;login is good also)

http://www.usenix.org/events/sec01/craver.pdf

If you want to read more, check out this FAQ by the people that broke the SDMI digital watermark a few years ago. They also have the actual paper, which I read too, but have since forgotten.

http://www.cs.princeton.edu/sip/sdmi/faq.html

http://www.usenix.org/events/sec01/craver.pdf

seriously:

http://www.eecs.tufts.edu/~couch/software.html see Peep

now:

http://www.auralizer.com/

academic paper:

http://www.usenix.org/publications/library/proceed ings/lisa2000/gilfix/gilfix_html/

http://www.usenix.org/publications/library/proceed ings/lisa2000/gilfix/gilfix_html/

Peep (The Network Auralizer): Monitoring Your Network With Sound
Michael Gilfix & Prof. Alva Couch - Tufts University
Abstract

"Activities in complex networks are often both too important to ignore and too tedious to watch. We created a network monitoring system, Peep, that replaces visual monitoring with a sonic `ecology' of natural sounds, where each kind of sound represents a specific kind of network event. This system combines network state information from multiple data sources, by mixing audio signals into a single audio stream in real time. Using Peep, one can easily detect common network problems such as high load, excessive traffic, and email spam, by comparing sounds being played with those of a normally functioning network. This allows the system administrator to concentrate on more important things while monitoring the network via peripheral hearing."

"This work was supported in part by a USENIX student software project grant. "....

People have been happily predicting ubiquitous crypto for many years, but recently they don't so much, because they noticed that things haven't made any progress in that direction for the last decade or so. See Where has all the crypto gone?, a Usenix paper from five years ago, and ask yourself what progress has been made since then.

Don't get me wrong, I'd love to see it, but I'm not optimistic that it'll "just happen".

The original intent of RFC-1510 prohibited what Microsoft was trying to do, but Microsoft found what it claimed to be a loophole in RFC-1510 specification.
  http://www.usenix.org/publications/login/1997-11/e mbraces.html

The one in particular that comes to mind is this one from Usenix '05. https://www.usenix.org/events/sec05/tech/bethencou rt/bethencourt.pdf

Pretty much gives a technique for mapping out the location of these network telescopes or honeynets, which can later be used for avoidance.

There is no such thing as "mindless admin work" unless you are in a dysfunctional organization or you haven't got the mind to make the work into a research project. Read the presentations of a recent LISA (Large Installation Systems Administration) conference http://www.usenix.org/publications/library/proceed ings/lisa04/tech/, and you cannot call that work "mindless". Although Usenix has a historically Unix slant, there is no reason that creative engineering principles can't be applied to other OSs as well.

No. It was not that it was sponsored by Microsoft; it is that it was sponsored almost to its enterity by Microsoft and it was "invitation only", where invitations could come only from... Microsoft.

False. "Sponsored" by Microsoft means they donated money to it. It's a USENIX sponsored conference (which, if you're not aware, is an organization that sponsors highly respected systems conferences). It does not mean that Microsoft ran the show. Out of a 12 person committee, only two are from Microsoft Research.