Employment will be an agreement among equals when I can let my boss go due to "tough" financial times just like I can
You don't run the economy like your boss does, that's why he's the boss and you're not. He has responsibilities that you do not - like you have responsibilities that he does not have.
He most likely has more economical responsibility, which is why it will seem like he is the one who may let you go "due to tough financial times".
Should it turn out that you are a bad worker (like he would be a bad manager, should he have to let you go due to tough financial times), you will get him in trouble as well. It's not like competent employees are hanging on the trees in this world.
In other words: If you are the least bit worth your salt, he depends on you like you depend on him. If you're an incompetent sorry sod, he will probably kick you stupid ass. You can't kick his' if he's incompetent, but either his manager, or the cruel world of competition will have his ass for it.
Employment will be an agreement among equals when my boss invites me to his Christmas party
Reality check: A company is a hierarchical organization. In order to relieve the CEO of having to produce every single tidbit of machinery/documents/whatever it is the company is producing, workers are hired. In order to relieve the CEO from having to discuss every single little detail about everything with each and every worker, managers are hired. Depending on the size and type of the company, these all form a hierarchy of one-to-many relationships between upper-level folks to lower-level folks.
How many lower-level peopel does your upper-level person deal with? 10, 50, 100? You want him to invite every one of those for his private christmas party, or is it just you because you are special?
You know, I'm pretty sure he does invite some company people to a christmas party. Maybe he just doesn't like you. Or maybe he's afraid that you will not show up after all, because you never invited him to any party. After all, since (in most companies) the workers have fewer direct managers than the managers have direct workers, the workers could in reality ask their managers to a private christmas party, and have a pretty good chance of having the manager turn the offer down because he got too many invitations:)
Employment will be an agreement among equals when I get equal compensation for equal amounts of work and experience
How can a company afford to pay you? It's pretty simple - you produce value for the company, by means of whatever it is that you do. Either directly, by participating in creating a product for the customers of the company, or by aiding others in your company to produce such products.
If you cannot aid others in producing goods, and cannot produce goods yourself, you are a worthless person.
If you're good, or if the services you produce are somehow rare, there will be a demand for you in other companies. The companies will, by means of the free market, "bid" for your services. In other words, if you are such a valuable person, it will be easy to get a higher pay at another company - in order to keep your services, your current employer will most likely not be ignorant of this fact, and they can indeed be persuaded to increase your pay.
If they will not raise your pay, there are two options: Either go to another company that will give you the pay you demand - or discover that you are not as valuable as you thought you were, and accept the payment that you are getting.
Employment will be an agreement among equals when bosses and owners think of employment as an agreement among equals
Bosses and owners who do not think like this, are relics from a former era. They will go away, like the dinosaurs.
I think that if you actually have a chat, preferrably with some upper-level management guy in an informal setting, that you will find that they are actually quite human, and quite reasonable people.
If you direct manager is really an idiot (these exist), avoid him. But as you go up thru the levels, you should generally find a higher concentration of cluefull people.
I have known people who have the same views that you presented above. There is nothing that can hurt a company more, than an employer who believes strongly that the company is just a big monolithic chunk of "evil" that is solely feeding on the skills of the "poor" and "exploited" hard working "worker".
Just maybe, the company actually appreciates your work. And just maybe, they're a little bit tired of hearing you complain that they're extorting you, shovelling projects at you unfairly, not treating you as a person.
Just maybe, they actually like the productive little worker that hides behind your seemingly ignorant leftish front.
So this guy uses a piece of software for free. Good for him. Some day the publisher decides that they want to require payment for the service in the future - and they make him aware of this fact in advance.
And the first thing that pops up in this guys head is a lawsuit ?!!?
How about Intuit suing him for stupidity?
I mean, it's not like they ever promised him that they would make their services available to him for free, in all eternity...
Especially I find it amusing, that he wants a free software alternative - and would be willing to accept one that had basically so poor functionality that he could sue Intuit because of the conversion costs (from migrating from their free-as-in-beer services to some under-developed free-as-in-speech tool).
Like, "an alternative that is so crippled that I can't do business is ok, because I'll just move my business to lawsuits instead of doing productive work then".
And people wonder why the economy is going to hell... Sheesh...
Working in a company that ships a product (server written in C++, agent in C) on anything from NetWare over NT to Solaris HP-UX and Linux, I think I should chirp in here...
gcc-3.2 is pretty close to being C++ standards conformant. It is one *helluvalot* closer than VCPP 7 (the.net thingy) - and in my experience so far it is slightly better than Intel C++ 6.0 (the Intel compiler has Koenig lookup problems - and it suffers heavily from it's dependence on MS's poor excuse for an STL).
I'm sure you're mostly right about the performance - gcc probably doesn't generate "fast" code compared to Sun or SGI's compilers, on their respective platforms.
But in my oppinion you are wrong about g++ having any particularly annoying perculiarities, and you are *absolutely* wrong about msvcpp being anywhere *near* conformant to some standard resembling C++.
Hell, I had to put #ifdef __MSC_VER__ # define protected public #endif in certain header files in order to have them compile with msvcpp - how's that for a start... (and yes, the code is correct, it also compiles on g++ and intel's compiler - and the error is not something I can reproduce in a small example, it only happens in certain situations)
Why? Well it's basically what PDF is (PDF was made to be a successor to PS and has some extensions here and there, but let's not get all hung up about that for now).
You can *copy* a PostScript file to any reasonable printer produced in the last 10 years or so. And it will print - correctly and beautifully.
You have excellent interoperability - all UNIX and GNU/Linux systems will work out-of-the-box with PostScript.
For Windows you have "Ghostview" for windows (use google) as an alternative to the Acrobat reader. For printing, well define a standard PostScript printer in windows, and make it print to a file. Set up, for example, an Apple Laserwriter (with Postscript support) and point it to c:\temp\output.ps - voila! There's excellent interoperable standards-conformat PostScript output for you, to share with the world.
Why PDF was made, I never understood. But ok, people seem to use it, and it doesn't *remove* functionality that PostScript has (AFAIK).
xDoc? I see as little need for that, as I did for PDF. PostScript *still* does everything you could possibly want when it comes to simply exchanging pages of film-ready documents.
Both reading and authoring is available for free on any reasonable OS (LaTeX + ghostview) and in Windows (Word/whatever + ghostview/acrobat-something)
<rant> They measure the fan performance in cubic-fucking-FEET-per-minute
How about measuring in square-acres-per-yard-second? </rant>
One cubic feet is 28.317 litres. So, one cubic-(fucking)-feet-per-minute translates to 0.472 litres per second.
Now before anyone whines "oh but then litres per second is soooo inferior because something as simple as 1 cfm translates to some 0.472 litres persecond which is just soo much more difficult to remember", let's see what the *actual* airflows of the fans was. Oh, and one litre per second is 2.119 cf/m by the way.
Antec Blue LED Fan: 34.0 cf/m => 16.0 litres/second
Antec TriLight LED Fan: 34.0 cf/m => 16.0 litres/second
Cooler Master Neon LED Fan: 32.0 cf/m => 15.1 litres/second
Trying to "prevent itself from being killed" is the non-OS (M$) way of doing things. Of course none such ludicracy exists in a real kernel.
You have a security model. For example, a non-root user isn't allowed to kill a root process. This helps you not, if you run as root, but you do not end up running as root by "accident".
Further, running a system that has domain separation (TrustedSolaris, SELinux or others), improves the flexibility and granularity of the security model tremendously. In such a setup you could say that "my MUA is only allowed to access my mail data" - anything started by the MUA will run in the same domain (unless the security model has domain transition rules for that app. - which again would only be the case if the app was a part of the trusted computing environment).
What this gives you is, that no matter how crappy a MUA you use, there is *no* way that anything it gets from the net and decides to execute, can do anything more than the MUA itself. It would be trivial to create a domain from "internet apps" and have the application executing part of the MUA transition to that domain before executing anything. Then no amount of ingenuity on the part of the virus writer, and no amount of stupidity of the user and MUA developer is going to allow that virus to do *anything* more than display text in your mail window.
But then again, this requires that you use an OS with a decent security model.
And for some reason, which is beyond me, people still think that better security models make systems harder to use for the average user... Sigh... It takes the decision making *away* from the user, removing them from a burden, and guaranteeing that they (or their software) cannot screw up, deliberately or accidentally.
It really is that simple. Only, people refuse to accept it because it sound too damn good to be true.
Or, well, because there's no way M$ is going there and people feel they need crap on their drives.
What just puzzles me, is why noone has yet written a truely evolutionary virus.
Sometimes these "successfull" viruses come up, people don't bother to patch the vulnerabilities that let them in, but the virus still dies because AV software catches up. I think (but may be wrong) that it should be simple for a virus to work around that.
Let's say someone writes a virus. Now when the virus propagates, it copies itself (one way or another) to the new machines it infects. Why do viruses still make verbatim copies of themselves??
If the virus is written in VB, it should be a fairly simple matter to include in the virus, a routine which transforms VB source code. It should not do an equivalent transform, rather it should take numbers and change them, routines or single lines of code and flip them around. It could exclude lines of code. Or take existing lines of code, transform them and insert them at random places.
"But then some of the copies will not work" - yes, you are right. But if each virus spreads it's transformed offspring to 10 other hosts, it doesn't matter if 5 of the "children" are not viable. All in all, the "predators" (the AV software) will not be able to recognize the offspring just a few generations down the line.
Some of the offspring may stop propagating, or propagate more slowly. Some of it may propagate faster. Which is more beneficial, is something that will depend on how the AV software reacts to the spread.
In fact, calling any software a virus before it has the most basic functionality of it's biological equivalent is rediculous in my oppinion:)
I gave an example in VB. But certainly this can hold for machine executable code as well. It's just a little more tricky to determine which transforms are "reasonable", so that one doesn't end up with 99% nonviable offspring.
A web browser has become a fairly important part of an office workstation, and granted it was a problem when the browsers sucked.
What more does almost every person need - well a calendar, some contacts, and of course e-mail, are all pretty basic needs as well. I used ical once, it was "good enough". I use mutt for my personal e-mail, it "sucks less" that the other MUAs. Contacts? I haven't needed anything except for the aliases file for mutt, for my personal needs. At work I use Evolution, because it very conveniently integragtes these three functionalities - calendar, contacts and e-mail.
And that's it. I'm a developer, I don't need a friggin office suite - documentation is written in stable file formats (that still work even a year after they were written (.text or.tex)), code is written in C++.
If I was a beancounter I'd want a spreadsheet. If I was a marketing person I'd want a presentation program. As I'm a developer I need a compiler, an editor, and some tools to go with that.
I can't see that there's any "next new thing" in the near future. I bet it's another 10 years until we see some new technology that becomes ubiquitous like the browser did. Browsers came up in the mid/early '90s, as the newest technology by far. Outlook/Evolution - well the part that people need is just calendar, contacts and e-mail, and we've had that kind of software for decades. Outlook and Evolution just wrap the functionality in a pretty and easy to use interface. It's not new technology.
What I'm trying to get at is, that there are some "fundamental" needs - web, e-mail, calendar, contacts. Which we have covered more or less. Then there's "specific" needs, which depend on what your job is. A part of an office suite, for example, is a tool for a specific need. There's not going to be one killer "specific" application, since there's no killer job out there that 90% of us are going to occupy in a few years from now.
Specific stays specific. Fundamental got one small addition almost ten years ago, and that's it.
I haven't seen a printer without full Linux support since the days of the type-wheel printers.
Any decent laser has at least PostScript Level 2, which means it will eat data from any decent Linux application directly. We don't need no steeenkin' drivers !
That is why apps generate postscript. That is why printers eat postscript. That is why postscript is good:)
A device running at 120VAC can consume 4 Amps *without* consuming 480 Watts.
How? Well, most real-world devices are slightly (or sometimes not so slightly) inductive loads - this causes the current draw to lag after the voltage "peak" supplied.
In the DC world, your formula is valid: P = U * I, effect equals voltage times current.
In the AC world, it is still valid but it cannot be used the way that you used it. You multiplied the voltage with a current that was drawn at a different time - what you need to do is to find out the "power factor", the phase distortion (or whatever the english word for that is), of your devices.
The formula becomes:
P = U * I * cos(d) where d in most household devices would be anywhere from near-zero to 0.3 or so.
The minimum cos(d) is regulated by law, at least in Denmark and probably everywhere else, since the power companies have a hard time measuring and correcting phase distortion.
Anyway, what this all means is, that your devices probably only consume 60-80% of what you *think* you measured.
I mean, sure there's some "disable remote r00t" clickety-click somewhere - as long as you cannot verify what the OS actually does about it, it means squat. Nobody promised you it would also disable the "remote w00t r00t", or the "hidden remote secret root", or the...
There is one perfect solution: Keep proprietary OS machines off the network. Galvanic separation - no cable (and no antennas!) - works 100%
There is a less than perfect solution: Filter off all machines from vendor-X using products from vendor-Y. Make all machines from vendor-X resistant to attacks from the vendor-Y machines. Oh, and be damn sure that the two vendors are not affiliated, and are not controlled by the same government.
Sort of limits your options...
Unless you chose products where you can verify their operation. Note, this does not necessarily mean proof-reading the entire source, if the source is publicly available, the vendor is facing a mutual risk - *if* a backdoor is discovered he loses credibility and goes out of business, *because* there are alternative vendors available. Free Software is very clever in many ways that are not immediately obvious.
Re:Now change the name of KPP and KMAIL
on
KDE Gets The Hat
·
· Score: 2
I agree with you that the K naming is not intuitive - but hey, it's branding!
You want L'Oreal to change "Egoiste" into "Smell-good stuff", not to confuse consumers?
I completely understand that the K* people keep their naming like they do - some distros put more descriptive names in the menu, like "E-mail (KMail)".
After all, who wants to type "world\ wide\ web\ browser http://slashdot.org" in a shell anyway? No way - every moron out there knows what an "explorer" is, there is no reason why "konqueror" should be any different. Or kate. Or KPPP.
So my mother might not guess what KPPP is. But she wouldn't know what gdb is either - or Visual Studio or Maya for that matter.
It's not the K that confuses people. It the sudden availability of *choice*:)
AS/400 (with OS/400) runs all code in a virtual machine, and it relies on a number of compile-time checks (in combination with some run-time checks) to ensure reliable operation, like BRiX. There's no hardware support for memory protection needed, all in all it seems that the BRiX model is heavily inspired by AS/400.
The even cooler thing is, that since all 3rd party programs for AS/400 are distributed in byte-code (the only kind of code you can run on this system), to be run by the OS/400 virtual machine, the AS/400 product line has changed processors over time without needing any re-writes or even re-compilations of 3rd party products.
It seems that BRiX applications are machine-code - this kills off some of the coolness found in AS/400, unfortunately. It should get them some of the performance AS/400 cannot have, though.
Back in the good ol' days, AS/400 hardware did not have the support needed to perform memory access control in hardware - today they run on Power3 CPUs which has the support, but none of this matters for 3rd party products. All they do is run in the virtual machine, that's all they need to know.
However, porting apps from other OS'es is of course going to be a complete PITA. Not just porting to a completely different environment, but changing language at the same time. I guess that was what you meant when you said portability, and I completely agree there.
Anyway, just wanted to point out that there is at least one successful platform out there, built in a way similar to that of BRiX.
well anyway, here's at least one programmer who is looking forward to getting his mitts on a 64-bit chip which doesn't have layer upon layer of backwards compatibility, wrapped in an overpowered muscle-car of silicon.
Why wait?
This rig is half a decade old:
$ uname -a SunOS sol 5.8 Generic_108528-14 sun4u sparc SUNW,Ultra-1
You are right about the differences and the implications of the GPL. However, this is exactly the reason why Linux supports as much hardware as it does, and *BSD keeps lacking.
First of all, most likely you don't need all that much of a change in the kernel. There are the readl-time patches if you need those, and the kernel config options can do a lot. If you need special configurations, you're not really expsing yourself or your hardware by putting the patch on a publicly available FTP server which no-one would care to visit anyway.
If you need real code changes in the core kernel, there are two scenarios usually: either you're smoking crack and the problem already has a nice solution in the kernel - in which case the point is moot. Or, you're really on to something that could be used in general in the kernel, in which case you are not expsing your own hardware design, but will get the kernel changed for you (or at least have your patches accepted).
In the latter case, Linux moves a step forward. In either case, you get what you want without exposing your hardware significantly.
Finally, you may need to drive proprietary hardware pieces. Well, surprise, this is what modules are for. You are perfectly free to write a closed-source top-secret proprietary driver and load it as a module, without ever telling anyone that you even wrote it. And you can ship the binary module in your product, along with the kernel. No problem.
Oh, and in case you feel that you are not smoking crack and the kernel definitely needs a core change that you cannot get anyone to accept for inclusion, place hooks in the kernel code and make that patch publicly available. Now you can write your secret module and have it use those hooks.
No problem with the GPL as I see it. Just a general encouragement to make the kernel we all use a little better.
Does anyone know how big packets one can send thru such a pipe ?
100MBit maintained the same MTU as 10MBit, 1GBit maintained the same MTU too - leading to severe problems with performance. It's bad enough on 100Mbit, it's horrible on 1Gbit, to think that they maintained the 1500 byte limit on 10Gbit gives me the shakes...
Yes, I know about "jumbo frames", and I challenge you to find an affordable 1Gbit switch that actually supports it.
Anything below 64KByte packets would be insane as I see it.
Slashdot Mirror
Pardon my ignorance...
But how on earth would you want to do that with a Philishave ?!?
Employment will be an agreement among equals when I can let my boss go due to "tough" financial times just like I can
You don't run the economy like your boss does, that's why he's the boss and you're not. He has responsibilities that you do not - like you have responsibilities that he does not have.
He most likely has more economical responsibility, which is why it will seem like he is the one who may let you go "due to tough financial times".
Should it turn out that you are a bad worker (like he would be a bad manager, should he have to let you go due to tough financial times), you will get him in trouble as well. It's not like competent employees are hanging on the trees in this world.
In other words: If you are the least bit worth your salt, he depends on you like you depend on him. If you're an incompetent sorry sod, he will probably kick you stupid ass. You can't kick his' if he's incompetent, but either his manager, or the cruel world of competition will have his ass for it.
Employment will be an agreement among equals when my boss invites me to his Christmas party
Reality check: A company is a hierarchical organization. In order to relieve the CEO of having to produce every single tidbit of machinery/documents/whatever it is the company is producing, workers are hired. In order to relieve the CEO from having to discuss every single little detail about everything with each and every worker, managers are hired. Depending on the size and type of the company, these all form a hierarchy of one-to-many relationships between upper-level folks to lower-level folks.
How many lower-level peopel does your upper-level person deal with? 10, 50, 100? You want him to invite every one of those for his private christmas party, or is it just you because you are special?
You know, I'm pretty sure he does invite some company people to a christmas party. Maybe he just doesn't like you. Or maybe he's afraid that you will not show up after all, because you never invited him to any party. After all, since (in most companies) the workers have fewer direct managers than the managers have direct workers, the workers could in reality ask their managers to a private christmas party, and have a pretty good chance of having the manager turn the offer down because he got too many invitations
Employment will be an agreement among equals when I get equal compensation for equal amounts of work and experience
How can a company afford to pay you? It's pretty simple - you produce value for the company, by means of whatever it is that you do. Either directly, by participating in creating a product for the customers of the company, or by aiding others in your company to produce such products.
If you cannot aid others in producing goods, and cannot produce goods yourself, you are a worthless person.
If you're good, or if the services you produce are somehow rare, there will be a demand for you in other companies. The companies will, by means of the free market, "bid" for your services. In other words, if you are such a valuable person, it will be easy to get a higher pay at another company - in order to keep your services, your current employer will most likely not be ignorant of this fact, and they can indeed be persuaded to increase your pay.
If they will not raise your pay, there are two options: Either go to another company that will give you the pay you demand - or discover that you are not as valuable as you thought you were, and accept the payment that you are getting.
Employment will be an agreement among equals when bosses and owners think of employment as an agreement among equals
Bosses and owners who do not think like this, are relics from a former era. They will go away, like the dinosaurs.
I think that if you actually have a chat, preferrably with some upper-level management guy in an informal setting, that you will find that they are actually quite human, and quite reasonable people.
If you direct manager is really an idiot (these exist), avoid him. But as you go up thru the levels, you should generally find a higher concentration of cluefull people.
I have known people who have the same views that you presented above. There is nothing that can hurt a company more, than an employer who believes strongly that the company is just a big monolithic chunk of "evil" that is solely feeding on the skills of the "poor" and "exploited" hard working "worker".
Just maybe, the company actually appreciates your work. And just maybe, they're a little bit tired of hearing you complain that they're extorting you, shovelling projects at you unfairly, not treating you as a person.
Just maybe, they actually like the productive little worker that hides behind your seemingly ignorant leftish front.
What the fsck is wrong with people?
So this guy uses a piece of software for free. Good for him. Some day the publisher decides that they want to require payment for the service in the future - and they make him aware of this fact in advance.
And the first thing that pops up in this guys head is a lawsuit ?!!?
How about Intuit suing him for stupidity?
I mean, it's not like they ever promised him that they would make their services available to him for free, in all eternity...
Especially I find it amusing, that he wants a free software alternative - and would be willing to accept one that had basically so poor functionality that he could sue Intuit because of the conversion costs (from migrating from their free-as-in-beer services to some under-developed free-as-in-speech tool).
Like, "an alternative that is so crippled that I can't do business is ok, because I'll just move my business to lawsuits instead of doing productive work then".
And people wonder why the economy is going to hell... Sheesh...
Absolutely - you are *so* right.
The power shows itself by pressing tab twice:
$
Display all 2808 possibilities? (y or n)
*That* is power.
Working in a company that ships a product (server written in C++, agent in C) on anything from NetWare over NT to Solaris HP-UX and Linux, I think I should chirp in here...
.net thingy) - and in my experience so far it is slightly better than Intel C++ 6.0 (the Intel compiler has Koenig lookup problems - and it suffers heavily from it's dependence on MS's poor excuse for an STL).
gcc-3.2 is pretty close to being C++ standards conformant. It is one *helluvalot* closer than VCPP 7 (the
I'm sure you're mostly right about the performance - gcc probably doesn't generate "fast" code compared to Sun or SGI's compilers, on their respective platforms.
But in my oppinion you are wrong about g++ having any particularly annoying perculiarities, and you are *absolutely* wrong about msvcpp being anywhere *near* conformant to some standard resembling C++.
Hell, I had to put
#ifdef __MSC_VER__
# define protected public
#endif
in certain header files in order to have them compile with msvcpp - how's that for a start... (and yes, the code is correct, it also compiles on g++ and intel's compiler - and the error is not something I can reproduce in a small example, it only happens in certain situations)
What you really should do is to use PostScript.
Why? Well it's basically what PDF is (PDF was made to be a successor to PS and has some extensions here and there, but let's not get all hung up about that for now).
You can *copy* a PostScript file to any reasonable printer produced in the last 10 years or so. And it will print - correctly and beautifully.
You have excellent interoperability - all UNIX and GNU/Linux systems will work out-of-the-box with PostScript.
For Windows you have "Ghostview" for windows (use google) as an alternative to the Acrobat reader. For printing, well define a standard PostScript printer in windows, and make it print to a file. Set up, for example, an Apple Laserwriter (with Postscript support) and point it to c:\temp\output.ps - voila! There's excellent interoperable standards-conformat PostScript output for you, to share with the world.
Why PDF was made, I never understood. But ok, people seem to use it, and it doesn't *remove* functionality that PostScript has (AFAIK).
xDoc? I see as little need for that, as I did for PDF. PostScript *still* does everything you could possibly want when it comes to simply exchanging pages of film-ready documents.
Both reading and authoring is available for free on any reasonable OS (LaTeX + ghostview) and in Windows (Word/whatever + ghostview/acrobat-something)
Here's one for us unit-impaired:
<rant>
They measure the fan performance in cubic-fucking-FEET-per-minute
How about measuring in square-acres-per-yard-second?
</rant>
One cubic feet is 28.317 litres. So, one cubic-(fucking)-feet-per-minute translates to 0.472 litres per second.
Now before anyone whines "oh but then litres per second is soooo inferior because something as simple as 1 cfm translates to some 0.472 litres persecond which is just soo much more difficult to remember", let's see what the *actual* airflows of the fans was. Oh, and one litre per second is 2.119 cf/m by the way.
Antec Blue LED Fan:
34.0 cf/m => 16.0 litres/second
Antec TriLight LED Fan:
34.0 cf/m => 16.0 litres/second
Cooler Master Neon LED Fan:
32.0 cf/m => 15.1 litres/second
Enermax Adjustable fan:
94.92 cf/m => 44.80 litres/second
That kind of ideal capitalism shares two things with ideal communism:
1) none of them ever existed.
2) in the ideal world where they could exist, I'm sure they would solve all the problems the ideal world would not have to begin with
The real world sucks, get a helmet.
Trying to "prevent itself from being killed" is the non-OS (M$) way of doing things. Of course none such ludicracy exists in a real kernel.
You have a security model. For example, a non-root user isn't allowed to kill a root process. This helps you not, if you run as root, but you do not end up running as root by "accident".
Further, running a system that has domain separation (TrustedSolaris, SELinux or others), improves the flexibility and granularity of the security model tremendously. In such a setup you could say that "my MUA is only allowed to access my mail data" - anything started by the MUA will run in the same domain (unless the security model has domain transition rules for that app. - which again would only be the case if the app was a part of the trusted computing environment).
What this gives you is, that no matter how crappy a MUA you use, there is *no* way that anything it gets from the net and decides to execute, can do anything more than the MUA itself. It would be trivial to create a domain from "internet apps" and have the application executing part of the MUA transition to that domain before executing anything. Then no amount of ingenuity on the part of the virus writer, and no amount of stupidity of the user and MUA developer is going to allow that virus to do *anything* more than display text in your mail window.
But then again, this requires that you use an OS with a decent security model.
And for some reason, which is beyond me, people still think that better security models make systems harder to use for the average user... Sigh... It takes the decision making *away* from the user, removing them from a burden, and guaranteeing that they (or their software) cannot screw up, deliberately or accidentally.
It really is that simple. Only, people refuse to accept it because it sound too damn good to be true.
Or, well, because there's no way M$ is going there and people feel they need crap on their drives.
What just puzzles me, is why noone has yet written a truely evolutionary virus.
:)
Sometimes these "successfull" viruses come up, people don't bother to patch the vulnerabilities that let them in, but the virus still dies because AV software catches up. I think (but may be wrong) that it should be simple for a virus to work around that.
Let's say someone writes a virus. Now when the virus propagates, it copies itself (one way or another) to the new machines it infects. Why do viruses still make verbatim copies of themselves??
If the virus is written in VB, it should be a fairly simple matter to include in the virus, a routine which transforms VB source code. It should not do an equivalent transform, rather it should take numbers and change them, routines or single lines of code and flip them around. It could exclude lines of code. Or take existing lines of code, transform them and insert them at random places.
"But then some of the copies will not work" - yes, you are right. But if each virus spreads it's transformed offspring to 10 other hosts, it doesn't matter if 5 of the "children" are not viable. All in all, the "predators" (the AV software) will not be able to recognize the offspring just a few generations down the line.
Some of the offspring may stop propagating, or propagate more slowly. Some of it may propagate faster. Which is more beneficial, is something that will depend on how the AV software reacts to the spread.
In fact, calling any software a virus before it has the most basic functionality of it's biological equivalent is rediculous in my oppinion
I gave an example in VB. But certainly this can hold for machine executable code as well. It's just a little more tricky to determine which transforms are "reasonable", so that one doesn't end up with 99% nonviable offspring.
Just my 0.02 Euro on that one...
The numbers you're working with are the post numbers, not the user numbers.
:)
I posted after him, so my post number is higher than his.
I kid you not
With a 6 digit UID I doubt slashdot took five years of *your* life ;)
I think you're wrong. Mostly.
.tex)), code is written in C++.
A web browser has become a fairly important part of an office workstation, and granted it was a problem when the browsers sucked.
What more does almost every person need - well a calendar, some contacts, and of course e-mail, are all pretty basic needs as well. I used ical once, it was "good enough". I use mutt for my personal e-mail, it "sucks less" that the other MUAs. Contacts? I haven't needed anything except for the aliases file for mutt, for my personal needs. At work I use Evolution, because it very conveniently integragtes these three functionalities - calendar, contacts and e-mail.
And that's it. I'm a developer, I don't need a friggin office suite - documentation is written in stable file formats (that still work even a year after they were written (.text or
If I was a beancounter I'd want a spreadsheet. If I was a marketing person I'd want a presentation program. As I'm a developer I need a compiler, an editor, and some tools to go with that.
I can't see that there's any "next new thing" in the near future. I bet it's another 10 years until we see some new technology that becomes ubiquitous like the browser did. Browsers came up in the mid/early '90s, as the newest technology by far. Outlook/Evolution - well the part that people need is just calendar, contacts and e-mail, and we've had that kind of software for decades. Outlook and Evolution just wrap the functionality in a pretty and easy to use interface. It's not new technology.
What I'm trying to get at is, that there are some "fundamental" needs - web, e-mail, calendar, contacts. Which we have covered more or less. Then there's "specific" needs, which depend on what your job is. A part of an office suite, for example, is a tool for a specific need. There's not going to be one killer "specific" application, since there's no killer job out there that 90% of us are going to occupy in a few years from now.
Specific stays specific. Fundamental got one small addition almost ten years ago, and that's it.
I haven't seen a printer without full Linux support since the days of the type-wheel printers.
:)
Any decent laser has at least PostScript Level 2, which means it will eat data from any decent Linux application directly. We don't need no steeenkin' drivers !
That is why apps generate postscript. That is why printers eat postscript. That is why postscript is good
Well, since Greenland is still Danish territory, we are actually the seventh greatest nation in the world (area wise).
;)
However, I do see a problem getting the power from a huge windmill farm on Greenland across the atlantic
Exactly.
;)
A superconductive coil with a shield. This is incredibly more efficient than to pumping water uphill and the other conventional suggestions.
Only hope it doesn't accidentally heat up and lose it's superconductivity... *boom*
Get me two of what he got !
ROTFL
A device running at 120VAC can consume 4 Amps *without* consuming 480 Watts.
:)
How? Well, most real-world devices are slightly (or sometimes not so slightly) inductive loads - this causes the current draw to lag after the voltage "peak" supplied.
In the DC world, your formula is valid: P = U * I, effect equals voltage times current.
In the AC world, it is still valid but it cannot be used the way that you used it. You multiplied the voltage with a current that was drawn at a different time - what you need to do is to find out the "power factor", the phase distortion (or whatever the english word for that is), of your devices.
The formula becomes:
P = U * I * cos(d)
where d in most household devices would be anywhere from near-zero to 0.3 or so.
The minimum cos(d) is regulated by law, at least in Denmark and probably everywhere else, since the power companies have a hard time measuring and correcting phase distortion.
Anyway, what this all means is, that your devices probably only consume 60-80% of what you *think* you measured.
It's still a lot though, I'll give you that
On a proprietary system ?
...
Do you honestly believe that you can do this ?
I mean, sure there's some "disable remote r00t" clickety-click somewhere - as long as you cannot verify what the OS actually does about it, it means squat. Nobody promised you it would also disable the "remote w00t r00t", or the "hidden remote secret root", or the
There is one perfect solution: Keep proprietary OS machines off the network. Galvanic separation - no cable (and no antennas!) - works 100%
There is a less than perfect solution: Filter off all machines from vendor-X using products from vendor-Y. Make all machines from vendor-X resistant to attacks from the vendor-Y machines. Oh, and be damn sure that the two vendors are not affiliated, and are not controlled by the same government.
Sort of limits your options...
Unless you chose products where you can verify their operation. Note, this does not necessarily mean proof-reading the entire source, if the source is publicly available, the vendor is facing a mutual risk - *if* a backdoor is discovered he loses credibility and goes out of business, *because* there are alternative vendors available. Free Software is very clever in many ways that are not immediately obvious.
I agree with you that the K naming is not intuitive - but hey, it's branding!
:)
You want L'Oreal to change "Egoiste" into "Smell-good stuff", not to confuse consumers?
I completely understand that the K* people keep their naming like they do - some distros put more descriptive names in the menu, like "E-mail (KMail)".
After all, who wants to type "world\ wide\ web\ browser http://slashdot.org" in a shell anyway? No way - every moron out there knows what an "explorer" is, there is no reason why "konqueror" should be any different. Or kate. Or KPPP.
So my mother might not guess what KPPP is. But she wouldn't know what gdb is either - or Visual Studio or Maya for that matter.
It's not the K that confuses people. It the sudden availability of *choice*
AS/400 (with OS/400) runs all code in a virtual machine, and it relies on a number of compile-time checks (in combination with some run-time checks) to ensure reliable operation, like BRiX. There's no hardware support for memory protection needed, all in all it seems that the BRiX model is heavily inspired by AS/400.
The even cooler thing is, that since all 3rd party programs for AS/400 are distributed in byte-code (the only kind of code you can run on this system), to be run by the OS/400 virtual machine, the AS/400 product line has changed processors over time without needing any re-writes or even re-compilations of 3rd party products.
It seems that BRiX applications are machine-code - this kills off some of the coolness found in AS/400, unfortunately. It should get them some of the performance AS/400 cannot have, though.
Back in the good ol' days, AS/400 hardware did not have the support needed to perform memory access control in hardware - today they run on Power3 CPUs which has the support, but none of this matters for 3rd party products. All they do is run in the virtual machine, that's all they need to know.
However, porting apps from other OS'es is of course going to be a complete PITA. Not just porting to a completely different environment, but changing language at the same time. I guess that was what you meant when you said portability, and I completely agree there.
Anyway, just wanted to point out that there is at least one successful platform out there, built in a way similar to that of BRiX.
Why wait?
This rig is half a decade old:
$ uname -a
SunOS sol 5.8 Generic_108528-14 sun4u sparc SUNW,Ultra-1
KDE stands for: ;)
(The) Kalle Dalheimer Experience
(See http://www.kde.org/people/kalle.html)
You are right about the differences and the implications of the GPL. However, this is exactly the reason why Linux supports as much hardware as it does, and *BSD keeps lacking.
First of all, most likely you don't need all that much of a change in the kernel. There are the readl-time patches if you need those, and the kernel config options can do a lot. If you need special configurations, you're not really expsing yourself or your hardware by putting the patch on a publicly available FTP server which no-one would care to visit anyway.
If you need real code changes in the core kernel, there are two scenarios usually: either you're smoking crack and the problem already has a nice solution in the kernel - in which case the point is moot. Or, you're really on to something that could be used in general in the kernel, in which case you are not expsing your own hardware design, but will get the kernel changed for you (or at least have your patches accepted).
In the latter case, Linux moves a step forward. In either case, you get what you want without exposing your hardware significantly.
Finally, you may need to drive proprietary hardware pieces. Well, surprise, this is what modules are for. You are perfectly free to write a closed-source top-secret proprietary driver and load it as a module, without ever telling anyone that you even wrote it. And you can ship the binary module in your product, along with the kernel. No problem.
Oh, and in case you feel that you are not smoking crack and the kernel definitely needs a core change that you cannot get anyone to accept for inclusion, place hooks in the kernel code and make that patch publicly available. Now you can write your secret module and have it use those hooks.
No problem with the GPL as I see it. Just a general encouragement to make the kernel we all use a little better.
Does anyone know how big packets one can send thru such a pipe ?
100MBit maintained the same MTU as 10MBit, 1GBit maintained the same MTU too - leading to severe problems with performance. It's bad enough on 100Mbit, it's horrible on 1Gbit, to think that they maintained the 1500 byte limit on 10Gbit gives me the shakes...
Yes, I know about "jumbo frames", and I challenge you to find an affordable 1Gbit switch that actually supports it.
Anything below 64KByte packets would be insane as I see it.
Anyone knows ?