SPDY is an HTTP-compatible protocol built upon TCP. QUIC is a fully-experimental protocol based on UDP.

Of course the Linux that was in the mid-to-late 90s is dead, but it's not difficult to rebuild kernels, or have weird configurations at all.

I've got a Linux box running on a set of eclectic hardware working as an arcade machine. The monitor needs very special and specific modelines to run, hates KMS, and has some hardware that does not work right under the standard HID input driver. The machine is currently running Fedora 18 and I build a custom kernel with a patch for HID and KMS, and a very funny looking X config. This stuff is not any harder to do, in fact building a kernel was easier than back in the day. "make install" will actually put the kernel into grub, throw it in /boot and make an initrd for you.

Of note, switching versions of complex software like X would break your system back then too, just as bad, if not more so. APIs back then were way more unstable, changing from time to time, and upgrading something that had a lot of dependencies would usually lead to breakage back then.

Honestly I'm glad that now people are predominately using stock distro kernels, making things saner in the support realm. It is not beautifully simple to build your own kernel if you don't know what you're doing. There's a huge amassing of various options, subsystems, and drivers that is daunting for someone who deals with low-level system configuration, let alone some new user. These distro kernels are much better for updating, are well-tuned for most applications (most people will not do better in hand-tuning a kernel, but it is possible to do better) and honestly it's not wasteful to use a few extra kilobytes for this or that in a kernel when you have gigabytes of memory.

If you want to go to something that requires by-hand configuration for every component and doesn't have the ability to configure itself to reasonable defaults, be my guest! I'll stick with things that work most of the time, personally.

> So, it's like the Debian installer, only less powerful and more confusing!

Well, yeah, but it's a lot of new code for this release. I'm hoping in Erwin's Kitty they will have an advanced button that will help out. If nothing else, at least have a way to get more package granularity.

Why is providing feedback whining to you? I find it to be more helpful than random patches or other contributions.

Thing is, I don't want everyone and their brother submitting patches to a project I work on. I prefer the coding to be done by a core group of people I've vetted and know they are willing to maintain what they submit. I'd much rather get feedback to see if my ideas are headed in the right way my userbase wants it to be headed. Sure, I don't always go in that direction, but it's helpful to see what they want. And it way beats a poorly written patch submitted by someone who doesn't want to maintain it.

Sure, making a skeleton kernel based on existing documents isn't too bad. Booting x86 is a pain in the ass, but not hard for an experienced programmer, but making a working system that has everything it needs is quite a different challenge. If it's so easy to make a kernel, how come the GNU project still can't produce a working kernel? HURD has been spinning it's wheels pretending to be something since 1990 (1986 if you count the previous attempt at making a kernel). If it were easy, why don't we have many more compatible kernels out there? The syscall interface for Linux is out there, one can make a fully binary compatible kernel if they want.

Besides, if GNU didn't exist, Linus would likely have used the MINIX userspace and then switched to the BSD one when he outgrew it. Sure, there are some nice things about GNU, but BSD would have done just as well.

Virtual machines are just a "computer within a computer", there's nothing about virtual machines per se that you won't really know from using modern computers. You will need to know specifics on software packages and tools for those packages, but those are very specific to the brand of virtualizing that you're doing.

Learning "virtual machines" is kind of meaningless in and of itself, and unless you have a pressing need to become an expert in a specific package, don't tie yourself to anything specific. If you're just trying to run linux and windows (or something similar) just do it; or if you're planning on an OS zoo, do that.

As far as desktop software goes, virtualbox is decent for free; but I've found it to be unstable if it's pushed too hard. Vmware workstation is much more stable, but a pain to pony up the cost.

Well, if an atheist were going around the way that Coppedge is reported to, yeah that would be trouble. You just should act like a dick. Civil discussion is fine where it's appropriate, but being a pushy dick isn't. Coppedge does have the right to say whatever he wants, and as the results of this court case shows, he was not fired for that.

Secondly, this whole thing is a tactic that the Christian right of getting into scientific or academic positions, being loudmouthed about their beliefs, and finally getting themselves canned for other reasons and shout that they are fired for being Christian. They do this to try and promote the idea that Christians are being persecuted, and that they need more recognition. It's a scummy tactic that these evangelical groups are trying to use to gain power. No, evangelicals, you are not being persecuted in this country; just because someone tells you to be quiet in a place you aren't supposed to be mouthing off about anything doesn't make it an oppression of your religion; no, because something is offensive to your beliefs does not make it an attack on your beliefs, you have no right to be not offended.

The original claims, though, were that a calorie restricted diet will improve lifespan over a sufficient, normal, healthy diet.

If you are lucky enough to be in IL or another state with a top-rated uni in CS with an articulation initiative, go to community college, get the requirements there, and get in. That's what I did. Of course, this was about 2.5 years ago, but, hey, it worked for me.

So, many people keep wondering why use SUA vs Cygwin?

Well, first off the basic thing is speed. SUA has kernel hooks for syscall translation. It's able to do many of the POSIX syscalls in a much quicker fashion than Cygwin. Cygwin, on the other hand, does *everything* for POSIX syscalls in userland, causing it to be slow (for example, a fork, at times can take *seconds* to complete).

So, SUA is much better this way... problem is, it's tricky to get things to compile for it, I never did get things building reliably for it. Cygwin has a full suite of programs already built, and it's much easier to build existing Linux/UNIX/POSIX programs for than SUA.

Being a Windows user who needs *NIX tools for many processing tasks, what do I use? Cygwin. Easier to set up and get running. The speed drives me insane, though. My login script, which runs many programs before bringing up my bash prompt will take 5-6 seconds.

Ideal solution: Hyper-V or some other VM software running a VM in the background that I can get a terminal to, that has filesystem access to my system drives too.

No wonder you're replying as an AC...

Most Universities have *very* well stocked libraries that are catered to the colleges. At my Uni we have millions of books at our disposal, *all* of the peer-reviewed journals for the fields taught and it's all kept up-to-date.

As far as the peer group is concerned, I'm about a half a year behind most of my immediate peers, and they are *all* going off to prestigious jobs in the bay and in Seattle.

Structure is an important part of the curriculum here, and while structure may not suit some, it's a good approach for most when coming to learn a diverse and complex field. CS and computer engineering are both extremely diverse, and without some structure to learn the basics and roots, you will have a much poorer experience.

Experts. Flat out. I have interacted with some of the most amazing professors in their fields. People like Jeff Erickson and Sanjay Patel. The *real* experts are not only patient, but understanding, and when you have a need to go to them, they help you to the best of their ability.

Time. You have four years where you're exploring academia. You can prod and poke at areas of interest to find what suits you. To find out what you want to make your name in. You can even pick a spot and explore further. It's rewarding for those who are willing. I actually returned after poo-pooing it the first time around. I'm so glad I did.

> Quick tip: when you attend a technical interview, answering the questions correctly doesn't get you the job. Being amazed at how much the interviewer knows does.

Wow... never at any of the places that I interviewed at was this true, and I've corrected interviewers on some points at times on some things (and got the job). Good people *never* feel threatened by someone who's smarter than them, in fact they welcome that person. I surround myself with people who are smarter than I am daily.

Good people will learn from the smarter people, not edge them out; they will work cooperatively to get the job done and get it done as well as possible.

From being someone who's been on both sides of the interview, both before and after education at a top school, I can say what you're claiming is quite BS except at poorly run places.

They don't? Gee... I guess I should put my projects in the bin then. I accomplished a pretty neat OS and CPU while I was in some classes; for required classes. My OS *almost* had DooM running and my CPU was written between me and a friend (our third party was pretty useless) was a pipelined CPU with cache, gshare predictor, BTB, etc built from bare logic components.

Class projects sure can show passion when you internalize them and take them seriously. When interviewing about these projects I talk about them with quite a bit of zeal.

<quote><p>
Applications you've made because of a school project will not count.</p></quote>

Well, I think it depends on the project. Sure, the maze solver for my data structures class isn't all too impressive, but for my software systems class the project is "write an OS" and for my computer organization class the project is "here's some gates, make a pipelined 16-bit CPU with x points of advanced features". Those two projects alone, if done well, are impressive on a resume.

> Maybe [snip]

Or, no.

Thing is, early computers were immensely different than the computers we have today. Addressing modes weren't fully thought out, instruction sets were esoteric and more suited for hand assembly, and even just getting information to/from memory wasn't quite what you'd expect. Both delay-line and drum memory were delay based, you had to have extremely tight timings to get the word you wanted.

Linux leverages many modern conveniences and paradigms. Without heavy modification, it cannot run on anything older than a M68000/i80386 processor with appropriate support hardware, and the older you go, the more you have to gut, change and cripple.