seriously Venik get over yourself. Solaris now does all those things and worse. It also has serious random performance regressions on certain hardware. It's generally much pickier and flakier than Linux, and the installer's shit as well. and Linux has become a lot better.
the interesting stuff in Solaris is all the new stuff. crossbow 10Gb+L4 preclass, zones, zfs, infiniband. sun might've leveraged the shit out of this, even with a fragile brittle platform. they can sell magical hardware that evades all the performance regressions. They can sell blade servers with top-of-rack switches that make IB cheap. They can take bites out of Hitachi/EMC/Netapp's market with storage based on IB and ZFS. Their kernel is better for modern AMD systems with dozens of cores. fragile and brittle is more okay for modern shops with 1000 servers instead of 2 servers. it's more about having a whole package that works together. That's what gave me hope for them and interest in them.
but this marketing necktie damage is probably too much.
OpenSolaris is a combination of redistributable binary blobs and CDDL open source parts, and is redundantly hosted on genunix.org so that if opensolaris.org disappeared tomorrow we could continue. In addition, I can legally copy my OpenSolaris LiveCD, and mirror (parts of? or all of?) the package depot.
Solaris 10 is nothing like that. You can download it legally only from Sun. so, if you had a commercial RTU before they changed their click-thru, AIUI anyway, you can still keep using it commercially for $0. However you can't get any more copies under those terms.
In the end, I think the binary blobs, CDDL's intentional incompatibility with GPLv2 and v3, the semi-dependence of OpenSolaris on the Sun Studio compiler, and their failure to win over a significant outside-Sun developer community will kill OpenSolaris if Oracle doesn't keep funding free development of the core OS.
The problem with the CDDL is mostly that it isn't the GPL, nor GPL-like enough: it doesn't have the same marketing power, and it isn't compatible with the GPL. And the other problem with OpenSolaris is that huge chunks of it are still binary.
You are semi-right that factors other than license will determine OpenSolaris's future, but for Solaris 10 license is absolutely the issue. There are two pieces to the announcement:
* Solaris 10 no longer $0
* OpenSolaris might be defunded.
The first is certain, and the second is very speculative AFAICT. The first is license-related, and the second is more complicated.
OpenSolaris is better than the non-IPS-based Solaris/SXCE builds IMHO so I'm not heartbroken to be forced off the Solaris 10 platform in general, HOWEVER other big fragile brittle Sun programs require Solaris 10 to work well, and won't work well or at all on a moving target like OpenSolaris. The one I know of is iPlanet, their MS Lookout killer email/calendar/... app. It's quite good, and it's also free-as-in-beer. I think there are other big, valuable non-Solaris userspace projects going on inside Sun, too.
Until this change, the s10brand looked like a good way to run these on OpenSolaris hardware inside a ``zone'' which is like a FreeBSD jail, which would be a ``branded zone'' meaning it can be solaris10 inside even though the outer kernel is newer OpenSolaris, so the brittle apps would be isolated from churn of the bare-metal OpenSolaris kernel. The branded zone is a way of really enforcing the kernel/userland boundary so the two can be upgraded independently, but in a rigorous and realistic way: for example packaging&patching, grub, zfs tools, ifconfig all get upgraded along with OpenSolaris without touching the Solaris10 inside the zone hosting iPlanet. It's a smart architecture, and I'd already changed from SXCE to OpenSolaris, gotten familiar with IPS 'pkg', installed s10brand and Solaris 10 in a zone, and started reading iPlanet install documents.
there is actually a LX brand for running Linux instead of solaris10, but it does not work well: it's Linux 2.4 / CentOS 3.8 only, and is not complete enough to run Apache. In contrast s10brand already works very well (no surprise there!), and it was this fact that originally swayed me to iPlanet rather than Zimbra, because Zimbra doesn't come packaged/supported to run smoothly on Solaris. Sun's work on s10brand had convinced me to use iPlanet rather than Zimbra, so eventually I might have paid for iPlanet support. (iPlanet is quite hard to maintain.) Good on them! Design a smart overall platform, and slowly, people will come. I was happy for both of us.
Because of this change I will probably either use Zimbra, or else use iPlanet on CentOS instead of Solaris, since both have committed licenses.
I'm interested in paying Sun for support, but I'm not interested in letting them rope me in with a bunch of monstrous interlinked packages I cannot separate from one another, then re-jigger the deal on one of the packages so I have to pay up or else redo months of work. I'm disappointed by how untransparent the change was: apparently it happened months ago, and took media and blogosphere (Ben Rockwood) sleuthing to uncover it. That's nothing new for Sun, though.
It's funny how free-as-in-beer seems good enough at first, but after about a decade, no matter how mercenary and narrowly-interested you THINK you are, you end up needing free-as-in-freedom.
And it doesn't matter if they recant, either, because now that they've changed their minds once, everyone knows they can change it again. From now on Solaris10 can talk-to-the-hand.
on OpenSolaris, ZFS is used to implement the Time Slider feature which is like Time Machine, only more proper. (space-efficient. roll-forwards and rollbacks are extremely fast. past clones are bootable. implementation is simple.) There's also an efficient incremental replication feature based on 'zfs send' and 'zfs recv' to handle the case of, for example, laptop user wants to back up the internal disk to a firewire external every night. They cannot seem to get their heads out of their ass to make the backup bootable without making a tiny edit to some stupid text file, but the foundation is really solid compared to the monstrous adhocness that is Time Machine.
Also OpenSolaris uses ZFS as part of the software update mechanism. The mechanism won't work without it. It's extremely useful because it lets you boot into a pre-update clone if something goes awry, or more likely if you encounter a bug (since all of open-source OpenSolaris is basically a beta testing pool for closed-source Solaris).
The snapshot/clone features of ZFS are extremely relevant to the desktop use-case.
There are some huge high-performance vendors in this space too like Bluearc and Isilon, and in addition to the already pretty intimidating (separate data/metadata cluster) NFS to SamFS/QFS gateway above, Sun is working aggressively (albeit slowly) on a new generation of cluster-backed (high-availability and not-limited-to-the-bandwidth-of-a-single-CPU) NFS stuff like pNFS, and NFS-to-Lustre gateways. It is not a mistake to make a commitment to NFS.
it'd be nice, though, if Apple would push all their netboot, LDAP, and software update cache tools as open source packages and get them integrated into CentOS or Ubuntu, the way they did with CUPS which works amazingly well. It's like they think they're doing some Microsoft Small Business Server thing with OS X Server, and it's just not on.
UltraSPARC II is one of the oldest UltraSPARC chips.
They had really good ECC on the DRAM---not only did ~all? of the SPARC machines even low end have ECC DRAM, but also when a stick went bad, 'dmesg' would tell you exactly which one to replace. Unlike PeeCees they really finish the job.
But prior to UltraSPARC III Cu, they didn't have ECC for the L2 cache. And the L2 cache on these chips was extremely large for their era, like 2MB on a 400MHz chip.
Part of what the poster might be referring to, is that the failure's nondeterministic. Once Sun support traces down one failure to L2 cache bit flips, every time something with a machine happens that they can't explain they'll say ``it's the L2 cache ECC problem, shrug, goodluck.''
It's probably a common practice with any engineers, which starts with the customer demand, ``no, you must work on my problem until you can explain the failure,'' which seems completely reasonable especially when you are paying them a fat yearly fee to do exactly this. Then you find yourself on the other side, and it's just impossible. It would be better if they were scientifically honest, but they're in a business position where this is impossible.
The big problem is when other parts of the culture start to internalize this scapegoating behavior. That's what's happening with ZFS now, where people like Richard Elling blame this corrupt ueberblock problem on bit-flip gremlins. The argument goes, ZFS gives you an error message like ``corruption detected'', and they read the error message and say ``oh the self healing couldn't work because you didn't have redundancy at the zpool layer. See, it says right there, corruption.'' They're using ZFS's error message to exhonerate ZFS, along with a bunch of anecdotal hypotheticals on which they don't follow up.
The problem tends to happen when you reboot an iSCSI target without rebooting the host. It's ok to reboot an iSCSI target, so long as you also cord-yank the host while the target is missing. If you don't, you can imagine a stream of writes headed toward the drive with a few writes in the middle just knocked right out. I think there's a problem with the error recovery state machine in the iSCSI initiator or ZFS or somewhere else in the storage stack. The NFS client-server connection can recover perfectly if the server reboots and the client doesn't, but I'm not sure iSCSI is up to the same level. You can imagine the same type of problem happening with a USB/Firewire drive that goes away while mounted _and then comes back_---something in the USB layer might auto-retry a few times thinking the USB connection is noisy, finally get through, and courteously hide this failure from the upper layers, but meanwhile unbeknownst to this hand-waving recovery state machine the USB drive has lost power, and (validly!) lost all the data in its write cache. The drive is allowed to do this, if it hasn't received and completed a SYNC CACHE command, but the upper layers of every filesystem we've got probably assumes lost-the-drive-write-cache event will happen only when the *host* also loses power so ideas like, ``you need to double-cache writes in the scsi disk driver and replay them if the drive goes away and comes back'' or ``you need to force-unmount filesystems on the slightest blip of complaint from USB/iSCSIinitiator layers'' are missing from most filesystems and storage stacks---so it is actually hurting other filesystems, too, but less disastrously. Unfortunately this is all unproven speculation from me, no better than the bitflip gremlins some ZFS fanboys are proposing.
The checksums on NetApp are not actually a single checksum but several at different layers in the storage stack. They adapted their checksums to the problems they were actually observing. Consequently, when a checksum seal is broken, it's helpful in tracking down where the problem happened. ZFS checksums, OTOH, often get broken when there's no silent corruption at all---for example, when half a mirror is out of sync. They're still doi
NetApp is the reason we have ZFS. I thought this was pretty obvious
Obvious? yet I'm the first person to mention it. Anyway there is not a problem with stating something that's obvious, as you seem to imply there is.
Are you trying to make the argument that SAN & NAS competes with local storage,
You just said that yourself, sorta. You said NetApp is the reason we have ZFS. Yeah, yeah, go ahead and redirect and tell me precisely what you mean which you will now flesh out to have nothing to do with ZFS in the NAS/SAN space.
But you'd be wrong if you did that. Yes, ZFS is absolutely designed to steal customers from the high-end NAS market. And if you read the OpenSolaris ZFS list, it's absolutely clear they are competitors. It's also a good fit for some SAN cases which is why it has zvol's---there are two iSCSI targets in OpenSolaris, iscsitadm and COMSTAR. The latter can emulate FC targets as well. Finally, Sun sells a NAS box, the 7000. It's based on ZFS plus some extra closed-source bits to make the web interface, and I would guess it's a different (newer) branch of Solaris as well since many ZFS bugs are fixed in the unstable nevada/opensolaris releases that are not fixed in Solaris 10.
They are also selling disk shelves based on SAS expanders designed to connect ~50 - 100 spindles to one CPU---basically they have a disk chassis with a pull-out CPU card, and if you use the CPU card you get an x4540 disk-heavy node, while if you use the SAS expander card you get dumb CPU-less storage with a few SAS interfaces that you can attach to a plain node. so on the hardware end, also, they are trying to increase disk density through using shelves and semi-proprietary head-to-shelf interconnects the same way as NAS/SAN market.
personally I think IB is a more interesting encroachment on the NAS/SAN space and wonder why it has not arrived yet. But Sun has invented some threats that are interestingly cheap to manufacture for what they do (unfortunately, not correspondingly cheap to buy!).
On Apple it would compete with XRaid if they would sell some dumb shelves. Even without dumb shelves people would make zpool's on their XRAID LUN's. Does XRAID do checksums? I don't know.
I cannot understand what corner you think you're in that would make you get all hostile towards ZFS.
I cannot understand why people can't read an extremely short fact-based post without having these blinding emotional ad-hominem reactions and trying to determine my corner so desperately they cannot hear the simple things I am saying.
The corner I'm in was: hearing someone say ZFS is revolutionary because it checksums data. which is bullshit since all the high-end vendors have been doing this for like a decade. ZFS tries to distinguish itself from other checksummers with the ``end-to-end'' language I mentioned, but I think the distinction's irrelevant. I think the more relevant distinction is that NAS/SAN vendors do *a lot* more testing. But ZFS does still encroach on their territory. You're wrong to think of it in a little ``local storage'' box.
How bout dem apples, NAS weanie?
I hate netapp. They are expensive and impossible to deal with. They squash the used market with contracts of adhesion that I think should be illegal. Their software is utterly proprietary. Their user community is these ``i don't care about politics I just want to get work done'' wankers who don't mind discussing their problems with a vendors' products on closed NOW forums censored by the vendor which you have to pay to access. It's a stifling, expensive, arrogant environment like Meraki, Allegro, Wolfram. In spite of the extremely high quality you are better off if you can stay well away from this kind of company. And although NetApp fucking works and ZFS is, kinda flakey, none of these problems apply to ZFS. however, all of that's a separate discussion than the one we were having about which ideas are new, revolutionary, or irreplaceable in ZFS.
Of course if you insist on reading every post with an implied thesis of "* sucks" or "* rules" then nothing is separate. You should stop doing that.
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.
I used solaris in the 90's then threw up my hands and walked away after the SunOS 4.x -> Solaris 2.x switch. I started again using Solaris about 1.5 years ago.
My view on them is different. I think the red tape is not excessive, and I VASTLY prefer the red tape to the arbitrary, unpredictable political dick-sucking pervasive in the Linux world that I ran into working on Linux/XBox. Also the download manager is optional, and the login/licenseagreement is for SXCE a.k.a. Nevada which does not have a redistributable license, so it's technically copyright violation to give it to your friend even though it's $0. OpenSolaris 2008.05 a.k.a. Nevada, and Nexenta, can be redistributed, which means no login or license agreement.
My two main problems are these:
* they misrepresent what features they actually have. They bragged about ZFS in Solaris 10 for a full *YEAR* before ZFS was actually IN Solaris 10, and they're still doing it, right now, where a bunch of nasty bugs are fixed in the development release that are not backported to stable Solaris 10.
of course Linux pulls this crap pretty horribly, too.
* they misrepresent the open-sourceness of their software. Initially OpenSolaris was not a self-hosting operating system, but just a random collection of source code that you could build, on proprietary closed-source $0 SXCE, and then install overwriting PARTS of your system. The initial source release was really tiny, like less than 100MB tarball. However the thing referred to by the word OpenSolaris, though not an operating system, at least was all open-source.
now OpenSolaris is a full operating system, but it does not come with source. It's a redistributable BINARY release on CD-ROM.
you can download the source for part of OpenSolaris, but not the whole thing. It's not like Linux or BSD at all, yet people think it is.
* They claim that ``all new things added to Solaris will be open-source,'' and we will make some slow best-effort progress at opening the old things. They do not meet the claim, though: they don't sell any hardware (neither SPARC nor x86) for which all open-source drivers are available. It's bad enough that Sun has the power to choose chip-by-chip a collection of hardware for which writing drivers without NDA is possible, and mass-purchasing leverage with vendors, neither of which Linux has. But almost always the same chip with the closed-source driver in Solaris has a FOSS driver in Linux, and frequently the Linux driver is working better.
These are irc logs from our small network, irc.2600.net. r0d3nt and I are opers there. We're being DDoSed right now, we're pretty sure by these same foonet guys. I AKILLed this md5k from our network because he DDoSed us and then bragged about it, and predictably they've been attacking us on and off for the last week.
Some of our friends contributed to the original investigation against these foonet posers. We're gathering logs to contact ISPs and the old group at the FBI who originally investigated them. so, here we go again.
-----8<----- * Now talking on #chatz r0d3nt whats up ? raziel Greetings r0d3nt raziel We have been sent here at the behest of someone who we consider a friend. r0d3nt for what purpose ? * raziel removes channel operator status from raziel raziel To talk. r0d3nt about ? raziel I was told by this someone, whom I think you know who it is. That you are a reasonable man. r0d3nt ok raziel This someone personally means a great deal to us. raziel Why he enjoys this net I really dont know. No offence r0d3nt none taken. raziel Yet here we are on the very edge of what we consider to be a foolish move on the part of 2600. r0d3nt which was ? for clarification.. raziel By now its obvious this someone has quite the following and abilities to have us...his crew begin a war which well never end. raziel What I dont understand is why these facts were known, after he apologized..which one again I dont think he should be here anyway, But alas he likes the company of that little news chan of his. r0d3nt i explained to emmanuel he apologized, this evening. raziel So being two intelligent men, surely we have better things todo with this. r0d3nt i certainly hope so. raziel To our knowledge he is akilled for 1 month. r0d3nt i believe so... raziel And I simply state the truth when I say this no "chest thumping" as it were. We are resolved to explain one way or another be it 24/7 why we think that akill is a mistake. raziel Today has been a small kiddy demo of what is to come. You see r0d3nt he is not an a healthy man and I need not go into that further. r0d3nt i'm interested to know how you deal with users of this nature on your networks ? Surely you can see both sides of the "table"... raziel But for some odd reason it gives him happyness to be here with his news channel. raziel We dont personally care for 100% of the user count on my nets. raziel Him we do. r0d3nt I understand that to be true, but his actions don't give 2600net the same "feeling" raziel As men we know we make mistakes these things happen. r0d3nt of course.. raziel And to what we know all he did wrong was get drunk and act the fool. r0d3nt so what do you feel was/would be appropriate ? raziel Which he apologized for. raziel And was then without mercy akilled. raziel That is not very nice in our eyes. r0d3nt let me clarify.. what do you think would have been the appropriate action ? raziel Well honestly as much of a fool as he was acting as We did read the crap he did. raziel And he does speak of you as a friend... raziel Quite highly infact. raziel As a net staffer and his friend You should have seen his drunken state and given him a 24hr line timeout. raziel Thats how we handle these matters. raziel A 30 day akill is simply asking for where we are now. r0d3nt unfortunitly I wasn't around @ the time of the incidents and didn't have any input... well I see your perspective... raziel Wouldnt you say? raziel This certain someone long ago helped to build the first of the irc nets, his health is bad as I said for the time. But we will not leave his side..no matter how silly the issue is. raziel And In my opinion this is beneath the groups effort and time. r0d3nt ok raziel I bear the option of peace. raziel The question is will it be accepted? raziel Are we civi
It would be a lot easier to respond to your posting if you had included some hyperlinks. I am interested in your pet theories, but I don't have time to go searching for each one by hand.
The problem with fair queueing on modems is that the internal buffer inside the modem is usually quite large (on the order of 10 packets), and this buffer isn't subject to queueing. AFAIK the buffer must stay inside the modem for reasons of Tradition and V.42b. All real-time/fair queueing algorithms must muck with the output queue. For real network cards rather than modems, this means NIC drivers can reorder packets inside the FIFO onboard the network card. Each hardware NIC driver must have fair queueing support to deliver a good implementation. Therefore, it will never happen with traditional modems. You will have to buy a new modem, which may not exist yet.
I think you are talking about fair queueing w.r.t. ``Linux-diffserv'' because diffserv is the name of an IETF fair queueing working-group.
There is a lot of research on fair queueing. It deals with issues like the one you discuss, voice packets pre-empting large FTP packets. However, all the papers I've read are a much more advanced discussion than knee-jerk reactions like introducing another complexity into the protocol stack. They typically start with a GPS model in which each packet is 1 bit long, and then generalize the results for discrete packets. The ordering of the packets is actually a lot more interesting than their size.
This research was basically completed about five years ago with Hui Zhang's HFSC algorithm, which is implemented in the ALTQ package for *BSD. ALTQ is part of the KAME IPv6 stack that the three BSD's are importing into their trees and tracking as it evolves.
The relevant aspect of these algorithms is their ability to allocate bandwidth and latency separately and predictably. A high-bandwidth, high-latency FTP connection can share the same packet-switched link with a low-bandwith, low-latency VoIP connection. This is what ``real-time scheduling'' means. Although usually those words refer to CPU scheduling, the ideas and algorithms involved are similar if not identical.
This software is a real Computer Science answer to the age-old phone company allegations that only circuit-switched networks will ever reliably carry bounded-latency multimedia streams. It is not new, although it may be new to Linux or to popular use. If implemented on the whole Internet, it's basically proven that these algorithms can guarantee a clean, low-delay connection with no dropouts.
There are other papers about how to distribute some of the processing so these algorithms can scale to the core backbone, as well as stuff about extending them to wireless networks. Some of this research may be ongoing.
Anyone know which VoIP stacks work with IETF's diffserv ideas or RSVP?
We're here to serve the open source community. Period. If we ever fail or fall short in that mission, please don't hesitate to remind us.
This is exactly what we're doing right now, Larry. We are reminding you (if you want to call it that) that the open source community does not like it when publicly traded corporations buy news media organizations that report on them. This is not complicated, unreasonable, or understated.
Your purchase of Andover and thus Slashdot has turned into a giant publicity problem for your company. What's more, it's called our attentnion to something we didn't realize before: you also own freshmeat, themes, and sourceforge. You are buying up Open-source community infrastructure, and by the simple fact that you are a publicly-traded company, you are obviously doing this because you want to profit from it! I shudder to think of how.
If you want to serve the open source community, and in so doing garner lots of positive publicity for yourselves, I advise you to do the following:
Arrange for a well-publicized second release of Slashcode, while you still own Slashdot. This will make you perceived as a company that favours the open-source idea, in that you're publicly releasing some of your most valuable IP, and in so doing, giving news sites that compete with this one a head start.
Sell Slashdot to Rob & company for $1, and keep the rest of Andover for yourselves. This will make it abundantly clear, even to those who do not read or trust corporate-lawyer-written contracts, that you have no intention of controling the OSS community's news organizations. What's more, it will be so dramatic as to once again distract us from your ownership of lesser infrastructure like Freshmeat, Themes, and Sourceforge, which can thereafter be more freely manipulated toward your own ends, given your company's rock-solid reputation thereafter for respecting the freedom of OSS infrastructure.
No doubt we will continue to read more of your PR department's consoling press releases on this site. Meanwhile, I anxiously await a tangible response from you to our community's concerns.
Reading about all this stuff has made me realize how dependent I am upon Slashdot for my news. Up until now, I kind of shrugged off the annoyance that all my friends were ``telling'' each other about the same Slashdot articles we had all read. Sure, Slashdot's good, but it was really kind of rediculous.
Editorial freedom for Slashdot or not, I'd like to diversify my newsreading by quite a bit, like maybe check in with five or ten sites on my own instead of just Slashdot or articles on other sites that Slashdot refers me to. What other sites to Slashdot-ers read to get their tech news?
It's real sweet to read about what lovely, lovely people are even within pissing distance of Slashdot, and how everyone knows them ``personally'' and can absolutely vouch for them, but this puts me in a difficult spot, because I do not know anyone ``personally,'' not the vouchers nor the vouchees. Your friends are not my friends, no matter how much you love them.
And I can't in good conscience give these character statements much creedence. I like Slashdot a lot and respect the work that went into it and the function it performs, which is more than several people I know would say. But, I find the personal testimonials distracting, and would like a more advanced sort of discussion about this issue.
Hey, i've got an idea. Let's deliberately not bastardize our so-called ``product'' with the mind-numbing marketing slogans that have so effectively kept the computer industry dominated by the lowest of technically inferior crap for the past fifteen years. Just maybe the reason Linux is here is because that strategy is a path to certain death and blazing failure! I don't care if you have the source code or not. If you deliberately scheme to keep people from thinking, whether it be through implanting ``brands'' into their brain or through any other scheme, you'll get exactly what we have right now.
You know, for all you say, the Microsoft stuff really isn't that bad. I mean, it does crash a lot, and I know it's supposed to be, like, evil or something, but frankly it does everything I need it to do, at work, and it all works together so nicely and I already know how to use it. Did you know I can take an Excel spreadsheet and put it in a Word document? and besides, everyone else is using Microsoft and I'm using it at work, so I need to use it or else I can't Collaborate with my Colleagues, and the next version is going to be even better than this one--and, frankly, I really just don't see what's wrong with it. It does everything I need it to. What you need to understand Mr. Fancypants Arrogant Computer Geek, sir, is that Real people have Real problems, and they need Real solutions, that work, and do what they need them to, not rediculous useless ideologies and arguments and discussions.
What is it that you want? Do you really want Linux to take over the world to the exclusion of every other competing operating system? Or do you want to see the blatant technical superiority over Microsoft that brought Linux to where it is today become the driving force behind an industry previously ruled by marketing geeks, greed, and the exploitation of fools?
I'm not saying you shouldn't advocate Linux. I'm simply saying it's grossly inappropriate to take marketing inspiration for a project like this one from giant megacorporations and television advertisements. People have a surprising amount of brain in them when you get them away from their TeeVee's--there are other ways to reach whatever audience interests you.
And if you don't care to try, you can always just cram it into an NC and shove it down their throat without their knowing, like IBM did with NetBSD.:)
I'm surprised to see no mention of scheduler activations, or the elegant asynchronous model developed by Inohara-san and Masuda-san. You can get the paper here:
There was a recent discussion on NetBSD's mailing list about implementing this high-performance thread architecture for NetBSD. You can read about it below, under the ``upcalls'' thread.
Tru64, Irix, and Solaris 2.6 all use scheduler activations. Linux does not. And IBM is not suggesting it. The Masuda Lab implementaiton is slightly better than scheduler activations and far more elegant. I do not think commercial OS's have adopted the Masuda & Inohara architecture.
Naive many-to-many without scheduler activations is simply not an efficient enough threading model. Note that all this research I have cited is over five years old, and yet Linus still wants kernel threads like NT uses (does he?). In my opinion, it is very important to keep current with a diverse array of research, because I've found that when I only pay attention to white papers and press releases from Intel, Sun, IBM, Ars Technica, whatever--I miss a lot of highly relevant work that later turns out to be every bit as essential as the usual wise softspoken few knew it was going to be from the beginning.
If you liked the IBM paper, I highly reccommend reading the ones I've referred you to. You might look at some academic papers on scheduler activations or threads in general from your neighborhood university library--they're surprisingly accessible even to people like me who aren't research studs.
I don't know much about IPv6 and haven't done anything to set it up on my system--i use the same/etc stuff i used when we had only IPv4. On NetBSD-current, I can verify that 'telnet::1' will get you a login prompt on the local machine. I didn't know::1 was the loopback addr until I read it here, so obviously I don't know enough to answer your DISPLAY question. NetBSD-current has merged into both the kernel and the userland the IPv6 stack developed in Japan by KAME. KAME supports IPsec, and KAME's IPsec implementation in NetBSD contains strong cryptography which can be legally downloaded both inside and outside the US. One of the KAME developers is active on the NetBSD mailing list, and continues to directly support the NetBSD port of KAME. IPv6-aware versions of popular tools like apache are available in NetBSD's pkgsrc, as well as directly from KAME.
Slashdot Mirror
seriously Venik get over yourself. Solaris now does all those things and worse. It also has serious random performance regressions on certain hardware. It's generally much pickier and flakier than Linux, and the installer's shit as well. and Linux has become a lot better.
the interesting stuff in Solaris is all the new stuff. crossbow 10Gb+L4 preclass, zones, zfs, infiniband. sun might've leveraged the shit out of this, even with a fragile brittle platform. they can sell magical hardware that evades all the performance regressions. They can sell blade servers with top-of-rack switches that make IB cheap. They can take bites out of Hitachi/EMC/Netapp's market with storage based on IB and ZFS. Their kernel is better for modern AMD systems with dozens of cores. fragile and brittle is more okay for modern shops with 1000 servers instead of 2 servers. it's more about having a whole package that works together. That's what gave me hope for them and interest in them.
but this marketing necktie damage is probably too much.
OpenSolaris is a combination of redistributable binary blobs and CDDL open source parts, and is redundantly hosted on genunix.org so that if opensolaris.org disappeared tomorrow we could continue. In addition, I can legally copy my OpenSolaris LiveCD, and mirror (parts of? or all of?) the package depot.
Solaris 10 is nothing like that. You can download it legally only from Sun. so, if you had a commercial RTU before they changed their click-thru, AIUI anyway, you can still keep using it commercially for $0. However you can't get any more copies under those terms.
In the end, I think the binary blobs, CDDL's intentional incompatibility with GPLv2 and v3, the semi-dependence of OpenSolaris on the Sun Studio compiler, and their failure to win over a significant outside-Sun developer community will kill OpenSolaris if Oracle doesn't keep funding free development of the core OS.
The problem with the CDDL is mostly that it isn't the GPL, nor GPL-like enough: it doesn't have the same marketing power, and it isn't compatible with the GPL. And the other problem with OpenSolaris is that huge chunks of it are still binary.
You are semi-right that factors other than license will determine OpenSolaris's future, but for Solaris 10 license is absolutely the issue. There are two pieces to the announcement:
* Solaris 10 no longer $0
* OpenSolaris might be defunded.
The first is certain, and the second is very speculative AFAICT. The first is license-related, and the second is more complicated.
OpenSolaris is better than the non-IPS-based Solaris/SXCE builds IMHO so I'm not heartbroken to be forced off the Solaris 10 platform in general, HOWEVER other big fragile brittle Sun programs require Solaris 10 to work well, and won't work well or at all on a moving target like OpenSolaris. The one I know of is iPlanet, their MS Lookout killer email/calendar/... app. It's quite good, and it's also free-as-in-beer. I think there are other big, valuable non-Solaris userspace projects going on inside Sun, too.
Until this change, the s10brand looked like a good way to run these on OpenSolaris hardware inside a ``zone'' which is like a FreeBSD jail, which would be a ``branded zone'' meaning it can be solaris10 inside even though the outer kernel is newer OpenSolaris, so the brittle apps would be isolated from churn of the bare-metal OpenSolaris kernel. The branded zone is a way of really enforcing the kernel/userland boundary so the two can be upgraded independently, but in a rigorous and realistic way: for example packaging&patching, grub, zfs tools, ifconfig all get upgraded along with OpenSolaris without touching the Solaris10 inside the zone hosting iPlanet. It's a smart architecture, and I'd already changed from SXCE to OpenSolaris, gotten familiar with IPS 'pkg', installed s10brand and Solaris 10 in a zone, and started reading iPlanet install documents.
there is actually a LX brand for running Linux instead of solaris10, but it does not work well: it's Linux 2.4 / CentOS 3.8 only, and is not complete enough to run Apache. In contrast s10brand already works very well (no surprise there!), and it was this fact that originally swayed me to iPlanet rather than Zimbra, because Zimbra doesn't come packaged/supported to run smoothly on Solaris. Sun's work on s10brand had convinced me to use iPlanet rather than Zimbra, so eventually I might have paid for iPlanet support. (iPlanet is quite hard to maintain.) Good on them! Design a smart overall platform, and slowly, people will come. I was happy for both of us.
Because of this change I will probably either use Zimbra, or else use iPlanet on CentOS instead of Solaris, since both have committed licenses.
I'm interested in paying Sun for support, but I'm not interested in letting them rope me in with a bunch of monstrous interlinked packages I cannot separate from one another, then re-jigger the deal on one of the packages so I have to pay up or else redo months of work. I'm disappointed by how untransparent the change was: apparently it happened months ago, and took media and blogosphere (Ben Rockwood) sleuthing to uncover it. That's nothing new for Sun, though.
It's funny how free-as-in-beer seems good enough at first, but after about a decade, no matter how mercenary and narrowly-interested you THINK you are, you end up needing free-as-in-freedom.
And it doesn't matter if they recant, either, because now that they've changed their minds once, everyone knows they can change it again. From now on Solaris10 can talk-to-the-hand.
no, bullshit. you are just sour-grapes-ing.
on OpenSolaris, ZFS is used to implement the Time Slider feature which is like Time Machine, only more proper. (space-efficient. roll-forwards and rollbacks are extremely fast. past clones are bootable. implementation is simple.) There's also an efficient incremental replication feature based on 'zfs send' and 'zfs recv' to handle the case of, for example, laptop user wants to back up the internal disk to a firewire external every night. They cannot seem to get their heads out of their ass to make the backup bootable without making a tiny edit to some stupid text file, but the foundation is really solid compared to the monstrous adhocness that is Time Machine.
Also OpenSolaris uses ZFS as part of the software update mechanism. The mechanism won't work without it. It's extremely useful because it lets you boot into a pre-update clone if something goes awry, or more likely if you encounter a bug (since all of open-source OpenSolaris is basically a beta testing pool for closed-source Solaris).
The snapshot/clone features of ZFS are extremely relevant to the desktop use-case.
I think NFS is a good alternative to AFP. I use it at my Mac shop, and it works really well once you figure out the automounter tricks, which in short is, on Mac OS X 10.4 and 10.5 the automounter works oddly much better if you use 'net' and let it pick where to mount the share.
Once you get that worked out, Macs get along quite nicely with standard NFS servers which gives you a huge complicated market from which to draw.
There are some huge high-performance vendors in this space too like Bluearc and Isilon, and in addition to the already pretty intimidating (separate data/metadata cluster) NFS to SamFS/QFS gateway above, Sun is working aggressively (albeit slowly) on a new generation of cluster-backed (high-availability and not-limited-to-the-bandwidth-of-a-single-CPU) NFS stuff like pNFS, and NFS-to-Lustre gateways. It is not a mistake to make a commitment to NFS.
it'd be nice, though, if Apple would push all their netboot, LDAP, and software update cache tools as open source packages and get them integrated into CentOS or Ubuntu, the way they did with CUPS which works amazingly well. It's like they think they're doing some Microsoft Small Business Server thing with OS X Server, and it's just not on.
UltraSPARC II is one of the oldest UltraSPARC chips.
They had really good ECC on the DRAM---not only did ~all? of the SPARC machines even low end have ECC DRAM, but also when a stick went bad, 'dmesg' would tell you exactly which one to replace. Unlike PeeCees they really finish the job.
But prior to UltraSPARC III Cu, they didn't have ECC for the L2 cache. And the L2 cache on these chips was extremely large for their era, like 2MB on a 400MHz chip.
Part of what the poster might be referring to, is that the failure's nondeterministic. Once Sun support traces down one failure to L2 cache bit flips, every time something with a machine happens that they can't explain they'll say ``it's the L2 cache ECC problem, shrug, goodluck.''
It's probably a common practice with any engineers, which starts with the customer demand, ``no, you must work on my problem until you can explain the failure,'' which seems completely reasonable especially when you are paying them a fat yearly fee to do exactly this. Then you find yourself on the other side, and it's just impossible. It would be better if they were scientifically honest, but they're in a business position where this is impossible.
The big problem is when other parts of the culture start to internalize this scapegoating behavior. That's what's happening with ZFS now, where people like Richard Elling blame this corrupt ueberblock problem on bit-flip gremlins. The argument goes, ZFS gives you an error message like ``corruption detected'', and they read the error message and say ``oh the self healing couldn't work because you didn't have redundancy at the zpool layer. See, it says right there, corruption.'' They're using ZFS's error message to exhonerate ZFS, along with a bunch of anecdotal hypotheticals on which they don't follow up.
The problem tends to happen when you reboot an iSCSI target without rebooting the host. It's ok to reboot an iSCSI target, so long as you also cord-yank the host while the target is missing. If you don't, you can imagine a stream of writes headed toward the drive with a few writes in the middle just knocked right out. I think there's a problem with the error recovery state machine in the iSCSI initiator or ZFS or somewhere else in the storage stack. The NFS client-server connection can recover perfectly if the server reboots and the client doesn't, but I'm not sure iSCSI is up to the same level. You can imagine the same type of problem happening with a USB/Firewire drive that goes away while mounted _and then comes back_---something in the USB layer might auto-retry a few times thinking the USB connection is noisy, finally get through, and courteously hide this failure from the upper layers, but meanwhile unbeknownst to this hand-waving recovery state machine the USB drive has lost power, and (validly!) lost all the data in its write cache. The drive is allowed to do this, if it hasn't received and completed a SYNC CACHE command, but the upper layers of every filesystem we've got probably assumes lost-the-drive-write-cache event will happen only when the *host* also loses power so ideas like, ``you need to double-cache writes in the scsi disk driver and replay them if the drive goes away and comes back'' or ``you need to force-unmount filesystems on the slightest blip of complaint from USB/iSCSIinitiator layers'' are missing from most filesystems and storage stacks---so it is actually hurting other filesystems, too, but less disastrously. Unfortunately this is all unproven speculation from me, no better than the bitflip gremlins some ZFS fanboys are proposing.
The checksums on NetApp are not actually a single checksum but several at different layers in the storage stack. They adapted their checksums to the problems they were actually observing. Consequently, when a checksum seal is broken, it's helpful in tracking down where the problem happened. ZFS checksums, OTOH, often get broken when there's no silent corruption at all---for example, when half a mirror is out of sync. They're still doi
NetApp is the reason we have ZFS. I thought this was pretty obvious
Obvious? yet I'm the first person to mention it. Anyway there is not a problem with stating something that's obvious, as you seem to imply there is.
Are you trying to make the argument that SAN & NAS competes with local storage,
You just said that yourself, sorta. You said NetApp is the reason we have ZFS. Yeah, yeah, go ahead and redirect and tell me precisely what you mean which you will now flesh out to have nothing to do with ZFS in the NAS/SAN space.
But you'd be wrong if you did that. Yes, ZFS is absolutely designed to steal customers from the high-end NAS market. And if you read the OpenSolaris ZFS list, it's absolutely clear they are competitors. It's also a good fit for some SAN cases which is why it has zvol's---there are two iSCSI targets in OpenSolaris, iscsitadm and COMSTAR. The latter can emulate FC targets as well. Finally, Sun sells a NAS box, the 7000. It's based on ZFS plus some extra closed-source bits to make the web interface, and I would guess it's a different (newer) branch of Solaris as well since many ZFS bugs are fixed in the unstable nevada/opensolaris releases that are not fixed in Solaris 10.
They are also selling disk shelves based on SAS expanders designed to connect ~50 - 100 spindles to one CPU---basically they have a disk chassis with a pull-out CPU card, and if you use the CPU card you get an x4540 disk-heavy node, while if you use the SAS expander card you get dumb CPU-less storage with a few SAS interfaces that you can attach to a plain node. so on the hardware end, also, they are trying to increase disk density through using shelves and semi-proprietary head-to-shelf interconnects the same way as NAS/SAN market.
personally I think IB is a more interesting encroachment on the NAS/SAN space and wonder why it has not arrived yet. But Sun has invented some threats that are interestingly cheap to manufacture for what they do (unfortunately, not correspondingly cheap to buy!).
On Apple it would compete with XRaid if they would sell some dumb shelves. Even without dumb shelves people would make zpool's on their XRAID LUN's. Does XRAID do checksums? I don't know.
I cannot understand what corner you think you're in that would make you get all hostile towards ZFS.
I cannot understand why people can't read an extremely short fact-based post without having these blinding emotional ad-hominem reactions and trying to determine my corner so desperately they cannot hear the simple things I am saying.
The corner I'm in was: hearing someone say ZFS is revolutionary because it checksums data. which is bullshit since all the high-end vendors have been doing this for like a decade. ZFS tries to distinguish itself from other checksummers with the ``end-to-end'' language I mentioned, but I think the distinction's irrelevant. I think the more relevant distinction is that NAS/SAN vendors do *a lot* more testing. But ZFS does still encroach on their territory. You're wrong to think of it in a little ``local storage'' box.
How bout dem apples, NAS weanie?
I hate netapp. They are expensive and impossible to deal with. They squash the used market with contracts of adhesion that I think should be illegal. Their software is utterly proprietary. Their user community is these ``i don't care about politics I just want to get work done'' wankers who don't mind discussing their problems with a vendors' products on closed NOW forums censored by the vendor which you have to pay to access. It's a stifling, expensive, arrogant environment like Meraki, Allegro, Wolfram. In spite of the extremely high quality you are better off if you can stay well away from this kind of company. And although NetApp fucking works and ZFS is, kinda flakey, none of these problems apply to ZFS. however, all of that's a separate discussion than the one we were having about which ideas are new, revolutionary, or irreplaceable in ZFS.
Of course if you insist on reading every post with an implied thesis of "* sucks" or "* rules" then nothing is separate. You should stop doing that.
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.
I used solaris in the 90's then threw up my hands and walked away after the SunOS 4.x -> Solaris 2.x switch. I started again using Solaris about 1.5 years ago.
My view on them is different. I think the red tape is not excessive, and I VASTLY prefer the red tape to the arbitrary, unpredictable political dick-sucking pervasive in the Linux world that I ran into working on Linux/XBox. Also the download manager is optional, and the login/licenseagreement is for SXCE a.k.a. Nevada which does not have a redistributable license, so it's technically copyright violation to give it to your friend even though it's $0. OpenSolaris 2008.05 a.k.a. Nevada, and Nexenta, can be redistributed, which means no login or license agreement.
My two main problems are these:
* they misrepresent what features they actually have. They bragged about ZFS in Solaris 10 for a full *YEAR* before ZFS was actually IN Solaris 10, and they're still doing it, right now, where a bunch of nasty bugs are fixed in the development release that are not backported to stable Solaris 10.
of course Linux pulls this crap pretty horribly, too.
* they misrepresent the open-sourceness of their software. Initially OpenSolaris was not a self-hosting operating system, but just a random collection of source code that you could build, on proprietary closed-source $0 SXCE, and then install overwriting PARTS of your system. The initial source release was really tiny, like less than 100MB tarball. However the thing referred to by the word OpenSolaris, though not an operating system, at least was all open-source.
now OpenSolaris is a full operating system, but it does not come with source. It's a redistributable BINARY release on CD-ROM.
you can download the source for part of OpenSolaris, but not the whole thing. It's not like Linux or BSD at all, yet people think it is.
* They claim that ``all new things added to Solaris will be open-source,'' and we will make some slow best-effort progress at opening the old things. They do not meet the claim, though: they don't sell any hardware (neither SPARC nor x86) for which all open-source drivers are available. It's bad enough that Sun has the power to choose chip-by-chip a collection of hardware for which writing drivers without NDA is possible, and mass-purchasing leverage with vendors, neither of which Linux has. But almost always the same chip with the closed-source driver in Solaris has a FOSS driver in Linux, and frequently the Linux driver is working better.
Some of our friends contributed to the original investigation against these foonet posers. We're gathering logs to contact ISPs and the old group at the FBI who originally investigated them. so, here we go again.
-----8<----- ...his crew begin a war which well never end. ..which one again I dont think he should be here anyway, But alas ... ...
* Now talking on #chatz
r0d3nt whats up ?
raziel Greetings r0d3nt
raziel We have been sent here at the behest of someone who we consider a
friend.
r0d3nt for what purpose ?
* raziel removes channel operator status from raziel
raziel To talk.
r0d3nt about ?
raziel I was told by this someone, whom I think you know who it is. That you
are a reasonable man.
r0d3nt ok
raziel This someone personally means a great deal to us.
raziel Why he enjoys this net I really dont know. No offence
r0d3nt none taken.
raziel Yet here we are on the very edge of what we consider to be a foolish
move on the part of 2600.
r0d3nt which was ? for clarification..
raziel By now its obvious this someone has quite the following and abilities
to have us
raziel What I dont understand is why these facts were known, after he
apologized
he likes the company of that little news chan of his.
r0d3nt i explained to emmanuel he apologized, this evening.
raziel So being two intelligent men, surely we have better things todo with
this.
r0d3nt i certainly hope so.
raziel To our knowledge he is akilled for 1 month.
r0d3nt i believe so...
raziel And I simply state the truth when I say this no "chest thumping" as
it were. We are resolved to explain one way or another be it 24/7 why we
think that akill is a mistake.
raziel Today has been a small kiddy demo of what is to come. You see r0d3nt
he is not an a healthy man and I need not go into that further.
r0d3nt i'm interested to know how you deal with users of this nature on your
networks ? Surely you can see both sides of the "table"
raziel But for some odd reason it gives him happyness to be here with his
news channel.
raziel We dont personally care for 100% of the user count on my nets.
raziel Him we do.
r0d3nt I understand that to be true, but his actions don't give 2600net the
same "feeling"
raziel As men we know we make mistakes these things happen.
r0d3nt of course..
raziel And to what we know all he did wrong was get drunk and act the fool.
r0d3nt so what do you feel was/would be appropriate ?
raziel Which he apologized for.
raziel And was then without mercy akilled.
raziel That is not very nice in our eyes.
r0d3nt let me clarify.. what do you think would have been the appropriate
action ?
raziel Well honestly as much of a fool as he was acting as We did read the
crap he did.
raziel And he does speak of you as a friend...
raziel Quite highly infact.
raziel As a net staffer and his friend You should have seen his drunken
state and given him a 24hr line timeout.
raziel Thats how we handle these matters.
raziel A 30 day akill is simply asking for where we are now.
r0d3nt unfortunitly I wasn't around @ the time of the incidents and didn't
have any input... well I see your perspective
raziel Wouldnt you say?
raziel This certain someone long ago helped to build the first of the irc
nets, his health is bad as I said for the time. But we will not leave his
side..no matter how silly the issue is.
raziel And In my opinion this is beneath the groups effort and time.
r0d3nt ok
raziel I bear the option of peace.
raziel The question is will it be accepted?
raziel Are we civi
The problem with fair queueing on modems is that the internal buffer inside the modem is usually quite large (on the order of 10 packets), and this buffer isn't subject to queueing. AFAIK the buffer must stay inside the modem for reasons of Tradition and V.42b. All real-time/fair queueing algorithms must muck with the output queue. For real network cards rather than modems, this means NIC drivers can reorder packets inside the FIFO onboard the network card. Each hardware NIC driver must have fair queueing support to deliver a good implementation. Therefore, it will never happen with traditional modems. You will have to buy a new modem, which may not exist yet.
I think you are talking about fair queueing w.r.t. ``Linux-diffserv'' because diffserv is the name of an IETF fair queueing working-group.
There is a lot of research on fair queueing. It deals with issues like the one you discuss, voice packets pre-empting large FTP packets. However, all the papers I've read are a much more advanced discussion than knee-jerk reactions like introducing another complexity into the protocol stack. They typically start with a GPS model in which each packet is 1 bit long, and then generalize the results for discrete packets. The ordering of the packets is actually a lot more interesting than their size.
This research was basically completed about five years ago with Hui Zhang's HFSC algorithm, which is implemented in the ALTQ package for *BSD. ALTQ is part of the KAME IPv6 stack that the three BSD's are importing into their trees and tracking as it evolves.
The relevant aspect of these algorithms is their ability to allocate bandwidth and latency separately and predictably. A high-bandwidth, high-latency FTP connection can share the same packet-switched link with a low-bandwith, low-latency VoIP connection. This is what ``real-time scheduling'' means. Although usually those words refer to CPU scheduling, the ideas and algorithms involved are similar if not identical.
This software is a real Computer Science answer to the age-old phone company allegations that only circuit-switched networks will ever reliably carry bounded-latency multimedia streams. It is not new, although it may be new to Linux or to popular use. If implemented on the whole Internet, it's basically proven that these algorithms can guarantee a clean, low-delay connection with no dropouts.
There are other papers about how to distribute some of the processing so these algorithms can scale to the core backbone, as well as stuff about extending them to wireless networks. Some of this research may be ongoing.
Anyone know which VoIP stacks work with IETF's diffserv ideas or RSVP?
Your purchase of Andover and thus Slashdot has turned into a giant publicity problem for your company. What's more, it's called our attentnion to something we didn't realize before: you also own freshmeat, themes, and sourceforge. You are buying up Open-source community infrastructure, and by the simple fact that you are a publicly-traded company, you are obviously doing this because you want to profit from it! I shudder to think of how.
If you want to serve the open source community, and in so doing garner lots of positive publicity for yourselves, I advise you to do the following:
- Arrange for a well-publicized second release of Slashcode, while you still own Slashdot. This will make you perceived as a company that favours the open-source idea, in that you're publicly releasing some of your most valuable IP, and in so doing, giving news sites that compete with this one a head start.
- Sell Slashdot to Rob & company for $1, and keep the rest of Andover for yourselves. This will make it abundantly clear, even to those who do not read or trust corporate-lawyer-written contracts, that you have no intention of controling the OSS community's news organizations. What's more, it will be so dramatic as to once again distract us from your ownership of lesser infrastructure like Freshmeat, Themes, and Sourceforge, which can thereafter be more freely manipulated toward your own ends, given your company's rock-solid reputation thereafter for respecting the freedom of OSS infrastructure.
No doubt we will continue to read more of your PR department's consoling press releases on this site. Meanwhile, I anxiously await a tangible response from you to our community's concerns.Editorial freedom for Slashdot or not, I'd like to diversify my newsreading by quite a bit, like maybe check in with five or ten sites on my own instead of just Slashdot or articles on other sites that Slashdot refers me to. What other sites to Slashdot-ers read to get their tech news?
I've got a few to start, but not many.
I anxiously await your suggestions.
And I can't in good conscience give these character statements much creedence. I like Slashdot a lot and respect the work that went into it and the function it performs, which is more than several people I know would say. But, I find the personal testimonials distracting, and would like a more advanced sort of discussion about this issue.
I'm not saying you shouldn't advocate Linux. I'm simply saying it's grossly inappropriate to take marketing inspiration for a project like this one from giant megacorporations and television advertisements. People have a surprising amount of brain in them when you get them away from their TeeVee's--there are other ways to reach whatever audience interests you.
And if you don't care to try, you can always just cram it into an NC and shove it down their throat without their knowing, like IBM did with NetBSD. :)
http://www.is.s.u-t okyo.ac.jp/tech-reports/TR94-02-letter.ps.gz
There was a recent discussion on NetBSD's mailing list about implementing this high-performance thread architecture for NetBSD. You can read about it below, under the ``upcalls'' thread.
http://mail-index.netbsd.org/tech-k ern/1999/12/
Tru64, Irix, and Solaris 2.6 all use scheduler activations. Linux does not. And IBM is not suggesting it. The Masuda Lab implementaiton is slightly better than scheduler activations and far more elegant. I do not think commercial OS's have adopted the Masuda & Inohara architecture.
Naive many-to-many without scheduler activations is simply not an efficient enough threading model. Note that all this research I have cited is over five years old, and yet Linus still wants kernel threads like NT uses (does he?). In my opinion, it is very important to keep current with a diverse array of research, because I've found that when I only pay attention to white papers and press releases from Intel, Sun, IBM, Ars Technica, whatever--I miss a lot of highly relevant work that later turns out to be every bit as essential as the usual wise softspoken few knew it was going to be from the beginning.
If you liked the IBM paper, I highly reccommend reading the ones I've referred you to. You might look at some academic papers on scheduler activations or threads in general from your neighborhood university library--they're surprisingly accessible even to people like me who aren't research studs.
I don't know much about IPv6 and haven't done anything to set it up on my system--i use the same /etc stuff i used when we had only IPv4. On NetBSD-current, I can verify that 'telnet ::1' will get you a login prompt on the local machine. I didn't know ::1 was the loopback addr until I read it here, so obviously I don't know enough to answer your DISPLAY question. NetBSD-current has merged into both the kernel and the userland the IPv6 stack developed in Japan by KAME. KAME supports IPsec, and KAME's IPsec implementation in NetBSD contains strong cryptography which can be legally downloaded both inside and outside the US. One of the KAME developers is active on the NetBSD mailing list, and continues to directly support the NetBSD port of KAME. IPv6-aware versions of popular tools like apache are available in NetBSD's pkgsrc, as well as directly from KAME.