If the modem can do it, why not? That's one less protocol layer to handle on your router.
I really don't see what makes a "router" special. My PC is in fact a router; it has a second ethernet port which I use with NAT to support a second device. If you run VMWare, you may have it in a mode that makes your PC a router. Those little cable modem sharing devices are routers. The big serious office/telco hardware also counts as "router" of course. What were you referring to?
Any of the above should be happy with the modem doing the PPPoE work. Some of the above can take on the job, but why?
a. don't want their minds and skills to rot b. get bored by the easy stuff c. are not stressed by difficult hacking (stress comes from office politics) d. like to be admired for their ability to do the difficult stuff e. like to be in the company of peers who can do the difficult stuff
You might get a great hacker doing lame stuff, but you'd have to pay him much MORE than you'd have to pay him to do the difficult stuff. The extra pay would compensate for the extra boredom. Since you can get a warm body for much less money, you're unlikly to hire the great hacker.
Since C#/.net is very lame compared to the challenges of something like OpenMosix, we can pretty reliably conclude that the supposed hacker is not really qualified to hack on OpenMosix. (alternate theory: his dad is the CEO and so the pay is quite absurd for the job being done)
I could maintain it. I have 7 to 10 coworkers who could maintain it. At my previous place there was one guy who could have maintained it. At the place before that, there were over a dozen people who could have maintained it.
I would in fact maintain it if I cared. I don't care.
BTW, I have doubts about the.net/c# guy you know. Most people who could maintain Mosix would not tolerate such work. They'd look down on it like a typical C++ developer looks down on HTML or Visual Basic development.
a. Bob's screen b. Joe's screen c. Bob's printer d. Joe's printer e. something arbitrary, like EMUs or TWIPs
Whatever you choose, it'll look ugly nearly everywhere unless you relax the idea of exact formatting. Text layout normally fits letters to the grid of pixels. When you change the device, you need to redo the grid fitting (changing layout) or live with blurry/uneven text.
On of the early astronauts, in the Gemini program I believe, punctured his glove. There was a metal part in his glove that got lose and poked a hole. He got a hole too; Earth now has little blood drops orbiting it.
Remember, we could be sending robots everywhere for the price of this. Science is not what NASA cares about. NASA cares about their budget. Going to Mars sells well. Going to Mars in skin-tight suits sells better.
The point is to protect off-site data. You can copy the data to a DVD-R, but you don't get the key. Take that DVD-R to another secure system which has the key though, and you can read the data.
If you do in fact have the key on your laptop, then you must have been authorized to carry the data around without encryption. That would be unusual.
The idea is that you can put an encrypted blob onto your insecure laptop, take this to a different secure machine which has the key, and then get access to the content on that secure machine. The laptop (or DVD-R, or CompactFlash) can't decrypt since it lacks the key.
Right from the initial install, by default, this should work.
Encrypted backups should be default and easy, with reminders.
You need multiple keys: whole-system, per-user, and swap. The swap key gets replaced at boot with something random.
Ultimately, it needs mandatory encryption. This would exclude OpenBSD; you need a mandatory policy framework like SE Linux to make it happen. Mandatory encryption means that normal users are prohibited from removing data from the machine without first encrypting it in an approved way. This most likely solves part of the backup problem. It also reduces the insider threat, while still allowing transfer of data between secure machines.
I do cross-platform code, and I look at the assembly output.
By "breaks the optimizer" I wasn't meaning incorrect output. I mean the optimizer gives up on the tangled mess, producing a rather unoptimized result. This affects both gcc 4.1 and Visual Studio 200x. (2005 I think -- the one after 2003)
Maybe you have some exotic compiler from Intel or Sun that does everything perfectly and has no bugs. The two most popular compilers (gcc and Visual Studio) have big trouble. Heck, neither will even get std::min right; the plain C macro produces better assembly code.
BTW, you're kidding about "standard from 2009 and on", right? The committee has shown little sense of shame before, but seriously... that'd be way over the top. It's creepy and sad that I should even wonder that you might not be joking.
Mach doesn't support much of anything until you add BSD.
The kernel contains a large chunk of the BSD kernel. Take BSD, rip out the memory management and scheduler, graft it onto a supposed microkernel that long outgrew "micro", and there you have it.
It's a trainwreak of a kernel, proving that the kernel alone doesn't make the OS.
First of all, it doesn't support my hardware. I'd have to buy an x86 or x86-64 system.
Then I'd lose my virtual desktops. Working without virtual desktops would be like running a marathon with my shoelaces tied together. It's too horrible to seriously contemplate; keeping 50 to 150 windows open would no longer be practical. I'd have to buy Photoshop ($$$), because gimp is unusable without virtual desktops.
Rather than using plain text files and shell scripts to get things done, I'd have to get lots of single-purpose software. (actually I'd go with Linux in a VM, but that's cheating) I'd have to blindly trust random little shareware apps to not be buggy or malware -- it's rare to get the source, and Vista doesn't include a compiler anyway.
I'd have to avoid putting critical personal data on the machine. I don't want my financial data leaking out via some spyware thing. I know many people take this risk, but I have too much to lose.
I'd have to stop going to certain web sites. (running Firefox is cheating; Vista's browser is IE7) The pop-ups would be awful at some of the places I visit. The malware is another concern.
It sounds miserable and hopeless. Maybe I'd just let the computer stay off and collect dust.
WTF? When are they going to support Firefox, Opera, and Safari?
The ActiveX, required for all downloads (to "optimize" downloads), is particularly evil. That only runs on Windows. When are they going to switch to something sane, like pure Java?
Really, they ought to just throw everything on an FTP site. They could use Bittorrent for the big ISO images. It works for Fedora.
I can well imagine that a linker would choke on Boost.
For those with a Linux/BSD/Solaris system, try running the "nm" command against a solidly Boost-infected project. You're likely to find function names that are THOUSANDS of characters long.
Think about what that means for program start-up, at least if you call into a library. The runtime linker has to chew through all that gunk. I've run a profiler on this kind of code, and sure enough the start-up time was dominated by looking up all those giant symbols.
Neither "goto" nor "longjmp" could be so bad. Exception handling takes you up the call chain, over some arbitrary number of calls, right out through arbitrary locations in your code. Holy crap! The bug potential is amazing, as is the obfuscation.
I haven't looked either, but I happen to know that BOOT::Python often does NOT work. It has thread-related problems.
At for the rest of BOOST, I've looked at a good chunk. BOOST makes decent programmers cry. The other follow-up post by the Anonymous Coward Xbox developer has it all correct.
I'll add:
BOOST is full of butt-ugly hacks. Check out the, uh, template things, named _0 through _9 being used as stand-in dummy arguments. Eeeeeew!!!
BOOST looks easy to dumb-ass programmers, but these programmers leave bugs that are difficult for expert programmers to find.
BOOST makes compilers run very very slow, and often breaks the optimizer anyway.
Some parts are NOT for newbie wimps, but the complex parts are well-justified. Most of the core code ("kernel" directory) is very clean and readable.
There are useful well-written abstractions, without the typical obfuscating layers of abstraction fluff.
The code is written to run fast, while still being portable and readable.
Static checking is all over, but not in-your-face annoying. Some of it involves compile-time assertions. Some of it involves a lint-like tool called "sparse" which makes sure that people don't do things like random math operations on bitmasks and wrong-endian data. Sparse also stops accidental (unsafe) use of user pointers from the kernel.
Slashdot Mirror
If the modem can do it, why not? That's one less protocol layer to handle on your router.
I really don't see what makes a "router" special. My PC is in fact a router; it has a second ethernet port which I use with NAT to support a second device. If you run VMWare, you may have it in a mode that makes your PC a router. Those little cable modem sharing devices are routers. The big serious office/telco hardware also counts as "router" of course. What were you referring to?
Any of the above should be happy with the modem doing the PPPoE work. Some of the above can take on the job, but why?
Yes, process migration is exactly that.
It's coming to standard mainline unmodified Linux too, judging by comments made by people supplying the container patches that keep getting accepted.
The really good hackers:
a. don't want their minds and skills to rot
b. get bored by the easy stuff
c. are not stressed by difficult hacking (stress comes from office politics)
d. like to be admired for their ability to do the difficult stuff
e. like to be in the company of peers who can do the difficult stuff
You might get a great hacker doing lame stuff, but you'd have to pay him much MORE than you'd have to pay him to do the difficult stuff. The extra pay would compensate for the extra boredom. Since you can get a warm body for much less money, you're unlikly to hire the great hacker.
Since C#/.net is very lame compared to the challenges of something like OpenMosix, we can pretty reliably conclude that the supposed hacker is not really qualified to hack on OpenMosix. (alternate theory: his dad is the CEO and so the pay is quite absurd for the job being done)
Being above, in terms of human rights, is relative to the viewer.
One must see himself as better. The alternative means that one should kill himself.
Iraqis should see themselves as better than Americans, and Americans should see themselves as better than Iraqis.
They are not related to your screen or printer, except indirectly via a twips-per-pixel conversion factor.
Other arbitrary units: meter, inch, furlong, chain, rod, parsec, lightyear, angstrom, pixel on somebody else's hardware, etc.
None of those are certain to neatly match up with device-specific pixels on every device.
The only truly non-arbitrary unit is the pixel on the current device.
I could maintain it. I have 7 to 10 coworkers who could maintain it. At my previous place there was one guy who could have maintained it. At the place before that, there were over a dozen people who could have maintained it.
.net/c# guy you know. Most people who could maintain Mosix would not tolerate such work. They'd look down on it like a typical C++ developer looks down on HTML or Visual Basic development.
I would in fact maintain it if I cared. I don't care.
BTW, I have doubts about the
What units do you use?
a. Bob's screen
b. Joe's screen
c. Bob's printer
d. Joe's printer
e. something arbitrary, like EMUs or TWIPs
Whatever you choose, it'll look ugly nearly everywhere unless you relax the idea of exact formatting. Text layout normally fits letters to the grid of pixels. When you change the device, you need to redo the grid fitting (changing layout) or live with blurry/uneven text.
On of the early astronauts, in the Gemini program I believe, punctured his glove. There was a metal part in his glove that got lose and poked a hole. He got a hole too; Earth now has little blood drops orbiting it.
He didn't notice until he got inside.
It's sex appeal.
Remember, we could be sending robots everywhere for the price of this. Science is not what NASA cares about. NASA cares about their budget. Going to Mars sells well. Going to Mars in skin-tight suits sells better.
The suit's pressure takes care of that. Everyone's dick looks the same, a paper thin wrap around your entire torso.
The point is to protect off-site data. You can copy the data to a DVD-R, but you don't get the key. Take that DVD-R to another secure system which has the key though, and you can read the data.
You won't be decrypting it without a key.
If you do in fact have the key on your laptop, then you must have been authorized to carry the data around without encryption. That would be unusual.
The idea is that you can put an encrypted blob onto your insecure laptop, take this to a different secure machine which has the key, and then get access to the content on that secure machine. The laptop (or DVD-R, or CompactFlash) can't decrypt since it lacks the key.
Right from the initial install, by default, this should work.
Encrypted backups should be default and easy, with reminders.
You need multiple keys: whole-system, per-user, and swap. The swap key gets replaced at boot with something random.
Ultimately, it needs mandatory encryption. This would exclude OpenBSD; you need a mandatory policy framework like SE Linux to make it happen. Mandatory encryption means that normal users are prohibited from removing data from the machine without first encrypting it in an approved way. This most likely solves part of the backup problem. It also reduces the insider threat, while still allowing transfer of data between secure machines.
I do cross-platform code, and I look at the assembly output.
By "breaks the optimizer" I wasn't meaning incorrect output. I mean the optimizer gives up on the tangled mess, producing a rather unoptimized result. This affects both gcc 4.1 and Visual Studio 200x. (2005 I think -- the one after 2003)
Maybe you have some exotic compiler from Intel or Sun that does everything perfectly and has no bugs. The two most popular compilers (gcc and Visual Studio) have big trouble. Heck, neither will even get std::min right; the plain C macro produces better assembly code.
BTW, you're kidding about "standard from 2009 and on", right? The committee has shown little sense of shame before, but seriously... that'd be way over the top. It's creepy and sad that I should even wonder that you might not be joking.
It helps. The problem doesn't go away.
Mach doesn't support much of anything until you add BSD.
The kernel contains a large chunk of the BSD kernel. Take BSD, rip out the memory management and scheduler, graft it onto a supposed microkernel that long outgrew "micro", and there you have it.
It's a trainwreak of a kernel, proving that the kernel alone doesn't make the OS.
I could never switch to Vista.
First of all, it doesn't support my hardware. I'd have to buy an x86 or x86-64 system.
Then I'd lose my virtual desktops. Working without virtual desktops would be like running a marathon with my shoelaces tied together. It's too horrible to seriously contemplate; keeping 50 to 150 windows open would no longer be practical. I'd have to buy Photoshop ($$$), because gimp is unusable without virtual desktops.
Rather than using plain text files and shell scripts to get things done, I'd have to get lots of single-purpose software. (actually I'd go with Linux in a VM, but that's cheating) I'd have to blindly trust random little shareware apps to not be buggy or malware -- it's rare to get the source, and Vista doesn't include a compiler anyway.
I'd have to avoid putting critical personal data on the machine. I don't want my financial data leaking out via some spyware thing. I know many people take this risk, but I have too much to lose.
I'd have to stop going to certain web sites. (running Firefox is cheating; Vista's browser is IE7) The pop-ups would be awful at some of the places I visit. The malware is another concern.
It sounds miserable and hopeless. Maybe I'd just let the computer stay off and collect dust.
Either VMWare or Paralels should do the job.
If you make Windows the guest, you also get Qemu+KVM.
We could pop up a warning when the user transmits a form to a Microsoft IIS server. ("This web site may be insecure...")
I'm sure Bill Gates will be happy to take some of his own medicine.
WTF? When are they going to support Firefox, Opera, and Safari?
The ActiveX, required for all downloads (to "optimize" downloads), is particularly evil. That only runs on Windows. When are they going to switch to something sane, like pure Java?
Really, they ought to just throw everything on an FTP site. They could use Bittorrent for the big ISO images. It works for Fedora.
I can well imagine that a linker would choke on Boost.
For those with a Linux/BSD/Solaris system, try running the "nm" command against a solidly Boost-infected project. You're likely to find function names that are THOUSANDS of characters long.
Think about what that means for program start-up, at least if you call into a library. The runtime linker has to chew through all that gunk. I've run a profiler on this kind of code, and sure enough the start-up time was dominated by looking up all those giant symbols.
You lost "pretty" right there.
Neither "goto" nor "longjmp" could be so bad. Exception handling takes you up the call chain, over some arbitrary number of calls, right out through arbitrary locations in your code. Holy crap! The bug potential is amazing, as is the obfuscation.
At least you admit to being uninformed.
I haven't looked either, but I happen to know that BOOT::Python often does NOT work. It has thread-related problems.
At for the rest of BOOST, I've looked at a good chunk. BOOST makes decent programmers cry. The other follow-up post by the Anonymous Coward Xbox developer has it all correct.
I'll add:
BOOST is full of butt-ugly hacks. Check out the, uh, template things, named _0 through _9 being used as stand-in dummy arguments. Eeeeeew!!!
BOOST looks easy to dumb-ass programmers, but these programmers leave bugs that are difficult for expert programmers to find.
BOOST makes compilers run very very slow, and often breaks the optimizer anyway.
Some parts are NOT for newbie wimps, but the complex parts are well-justified. Most of the core code ("kernel" directory) is very clean and readable.
There are useful well-written abstractions, without the typical obfuscating layers of abstraction fluff.
The code is written to run fast, while still being portable and readable.
Static checking is all over, but not in-your-face annoying. Some of it involves compile-time assertions. Some of it involves a lint-like tool called "sparse" which makes sure that people don't do things like random math operations on bitmasks and wrong-endian data. Sparse also stops accidental (unsafe) use of user pointers from the kernel.
You're pretty unaware of the state of humanity, probably because all YOUR classmates were going to college and could afford it.
The vast majority of people in the USA have never been to college, barely finished high school, and can't afford college.
There's nothing wrong with offering these people an opportunity. They have the right to refuse, though that might be a foolish decision.