Such machines can only yield a fraction of the energy it steals from the car, and the car is itself not very efficient in its use of energy. Such machines are a disaster both in economic and ecological terms -- they increase the waste in fossil energy, cost a lot to install, and yield but a fraction of what they destroy.
I'm sure something as stupid will be loved by all the government executives in the world: something inefficient and counterproductive, but that *looks* like it's doing some good, and helps rob people without their noticing -- my, that's government at its best!
does Friend Computer run? Is it Open Source? Is it based on code from Windows or Linux or MacOS or...
OK, I'll be heading to the nearest termination center. Though, ahem, could you give me the address of said center, or is it also classified above my security clearance? Nevermind, I didn't ask this quest<PROCESS TERMINATED>
There is a vast literature on parsing, and a lot of (mostly useless) parsing theory is a large part of the cursus in many CS departments. Check CiteSeer to get a glimpse of how much literature there is.
The best tools to build parsers and manipulate parsed syntax trees
are functional languages, such as OCaml
(with its streams parsers, camlp4, ocamllex/ocamlyacc, etc.),
or SML, Haskell, etc.
Of course, if you were a LISPer, you'd know that although you have lots
of well-known tools to build new parsers, such as
Meta or
Zebu,
the best thing to do about a parser is not to write it,
but rather to reuse the builtin extensible universal parser, READ,
and its extensible universal unparser, WRITE.
If you spend most of your time writing parsers,
you're not just using the wrong tools,
you're also using the wrong approach.
I have built a router out of a P75 (oc'ed to 90 MHz!), but I recently lost its IBM harddrive.
When I opened the case, I it was full of an inches-high structure of dirt. Most probably, the bad ventilation of the case caused the dust to accumulate which in turn prevented heat circulation and contributed to overheat the fragile drive.
The morale of the story is twofold:
most importantly Always keep up-to-date backups of everything you could hate to lose
be sure that dust doesn't accumulate inside your case. Think about it before removing fans, and check once in a while that dust didn't invade your computer.
You seem to have missed the main point: that the human is the weak link.
Of course a smart card is useful only if it does some crypto (otherwise it is but junk). But that does not suffice to guarantee security, and it is utterly stupid to pretend that "all crypto could be done on the smart card".
For instance, only whole-system security can guarantee the WYSIWYS property (What You See Is What You Sign) -- something essential for any legally binding signature: the security of the workstation where the user signs stuff is thus
of primary importance; don't run any unaudited or untrusted software on it.
Also, you'll still want to double the card security with normal password security; they don't fight the same kind of attacks, and the combination thus raises the security considerably.
Additionally, you might require a central (but replicated) server to stamp any document before it is considered binding, so as
to be able to keep track of what your company has signed. Otherwise, you might wake up with bad surprises, the day you learn you signed for millions worth of debt.
Finally, you must provide customers a trusted way
to check whether a certificate is signed, and what it really means --- the fact that the other contracting party may trust you is the whole point of a digital signature; if it does not participate in creating this contractual value, your digital certificate is not worth the electromagnetic field it is encoded with. Oh, and so that your customers may give any value to the contracts you signed, they must understand it, so
you'll want to include within the signed contracts a short and effective description of the contract, and not just a bookful of legalese (lawyers are more efficient than cryptographers at making a text unreadable).
The technical aspect of digital signature is well-known. OpenPGP and variants do everything you need.
The problem is that you can't keep those keys in a secure server watched 24/24 by armed guards --- you must hand them out (or hand a key to a key to a key) to the actual humans who will have to use them, and there you have a weak link in your security chain: how can you prove that the key can't be stolen? Or are you willing to be liable for anything signed with a stolen key?
Things can be enhanced by having some kind of physical key (a credit card or better, one of those small round things that you put in an actual keyring) attached to every person, to unlock his keys; usable only with his personal password at a secure desk within the walls of the company. Usual protection against Tempest are useful, to prevent anyone from stealing your passwords, etc.
If you find a cost effective way to manage digital signatures, you might find that you can make an awful lot of money selling the process to other companies, as part of streamlining their internal IT processes.
Have a hot career! Be a politician!
You can be in control of 60% of your country's gross income. You only have to be without scruple, a liar, or better, a man incapable of forming an opinion (thus you can't lie about it). You'll have to be a whore to public popularity - no demagogy is too small. You'll have to stand by the corporate interests of the political class: promote legislation as the magical solution to any and every problem in society. You'll have to be discreet about the way you privatize the money you extort from tax-payers.
Politician - here's the career of the past, present and future!
Disconnecting from the IRS
on
Disconnecting
·
· Score: 1
Now just you try to contact your government and tell them you want to end your subscription to their service!
This theory ignored the fact that the villagers mostly despised the current economic system and their obscenely corrupt government, and therefore welcomed the VC as prophets of change, but... never mind that.
Your theory also ignores the fact that the VC would murder anyone in those village who would be suspected of potentially not supporting VC.
When a few american soldiers committed a murder, the journalists would make a national scandal - and rightly so, perhaps. But when the VC used murder as a normal day-to-day tool to control population, nobody seems to make a big deal of it. And then, journalists conclude that somehow the US were the "bad guys" in this war, and the VC the "good guys".
Talk about racist double-standards!
You need some form of runtime barrier
that either statically prevents unsafe code from being called or dynamically prevents unsafe instructions from executing.
No, not runtime. Loadtime.
And typechecking is exactly that barrier.
Just use a typesystem adapted to your needs
(e.g. one that enforces you scoping, structure and linear types).
You seem not to have grokked
the concept of strong static typing
(which the TAL project demonstrated
to apply even to assembly language),
and even less the concept of proof-carrying code
(notably demonstrated by the FOX project).
Please stop thinking in terms of inferior languages
like C and Java as if they were the be-all end-all of computing.
If a module runs with limited privileges, security flaws in it can't be exploited to subvert the rest of the system
This is not the fact being denied.
The fact being denied is that runtime protection barriers would be a sensible way to limit privileges to begin with.
Development-time and compile-time protection methods are far more efficient:
Only use drivers for which you have source - it just doesn't make sense to fight against device drivers. Fight with them against bugs.
Use strong type systems: they can actually encode stronger are more precise privilege limitations than any runtime protection system will EVER be able to express.
Modularity is only useful as a source-level concept, not as a binary-level concept.
If it matters, instead of using the non-modular C language to build binary modules,
use instead a real modular language (SML, OCAML, Erlang, Dylan, Modula-3, whatever) to build your system.
Microkernels are a stupid idea.
on
Hurd: H2 CD Images
·
· Score: 2, Interesting
The very principle of a microkernel is stupid, and especially so for a free software OS.
See for instance this article against microkernels.
The basic premise behind a microkernel is that device drivers will be black box proprietary binary code from untrusted third parties, hence require clumsy run-time protection. This hypothesis has been invalidated in practice for proprietary systems, and doesn't even make sense in theory for free software systems.
There is no need whatsoever for expansive memory protection between modules at runtime. Modularity is great, but at development-time, not runtime.
HURD doesn't give you any additional development-time modularity; if anything, it removes it. If you want development-time modularity, drop that stupid C language, and use a modular language, such as Modula-3 (SPIN-OS), SML (Fox, Express), or Erlang (standalone Erlang).
Microkernels were the latest hype in the 1980's for OS development. They've only ever been hype, and it's sad that GNU people waste their time with such a stupid concept, whereas there's so much more to OS design, including lots of proven concepts, that just await to be implemented in free software (who's gonna implement the lost features from Genera? from Eumel?)
Using the C language to implement anything else but the lowest-level layers of a system is plain incompetence, all the more when security is involved.
The criterium is simple: if there is ANY use of dynamic allocation, you should use a safe language like OCAML, CommonLISP, Mercury, Perl, Python, etc. [Of course, C may be used when *implementing* the dynamic allocation].
If you're not satisfied of computing as it is today, then reinvent computing as it ought to be, so it will be tomorrow as you think it should be!
You might not want to join my own TUNES project, that is mostly vapourware at the point; but you'll find there plenty of inspiration as to how the future of computing can be imagined. Then, it's up to you to revive the project, found your own, or evolve some existing project toward something you like better.
And of course, there's no reason why you should be victim of off-by-one bugs.
There are already great languages with successful implementations that will
rid you of them, and provide features undreamed of by people brainwashed
with C/C++/Java.
Clean, Common LISP (CMUCL), Erlang, Haskell, Mercury, ML (OCAML, SML/NJ, ML-Kit), Oz (mozart), Scheme (MzScheme), Smalltalk (Squeak), and so many more, are already available, and can enable kinds of hacking impossible with lesser languages.
Just don't you use inferior systems and then complain about the braindeadness.
The only obstacle between your dreams and their implementation is YOU.
Why stand the slowness and incompatibility of framebuffer drivers, when you can have a full-screen, accelerated, compatible, X display?
You can have multiple X servers running,
one in each virtual terminal.
I have a set of scripts that automatically launch a new X server with some minimal twm setting, so as to run applications full screen: view DVI/PS/PDF documents, JPG/GIF pictures, HTML documents with embedded pictures, play games, etc.
Very handy when you're in a console switching period and your preferred window manager is the linux kernel's virtual terminal facility.
In case you don't want to roll your own from scratch, I can make my scripts available on request: they work very well for me, although it would require quite a lot of work to package them into a RPM, and you'll have to dig the CVS for versions that used to work with older X setups.
Functional programming languages will provide you
with great tools that will avoid most sources of
core-dumping:
OCaml is multithreaded (linuxthreads was born as a way to get it to work on linux), although
a single program won't take advantage of a multiprocessor. Core dump is impossible using
its static strong typing, and the optimizing
native-code compiler provides with great performance.
JOCaml is an extension of OCaml based on the
Join-Calculus, the latest and greatest paradigm
for distributed programming (can be seen as actor-based programming done right, as based on
a well-understood algebra). Can take advantage not only of multiprocessors, but of processor farms, or any distributed architecture, even heterogeneous architectures. Only bytecode can migrate, native code modules and primitives must be compiled into the servers.
Erlang is based on a paradigm quite similar to jocaml, but is designed for industrial applicability rather than hacker coolness; it has dynamic typing, a pure functional core (despite the logic programming syntax, it only has matching, not unification), enriched with explicit asynchronous communication primitives, and an implementation
that every phone call you make depends on, if you
use British Telecom. If you need tens of thousands of threads and/or lots of nodes, this is what you need.
There is also Mozart,
an distributed implementation of Oz, a real logic programming language (has unification).
Haskell and Mercury also have extensions for concurrent and distributed programming in the works, but I admit I don't know how usable they are for real programming.
Use real languages with a nicely designed
concurrent programming algebra, not fake languages that were never designed to begin with, and had a kluge of concurrent primitives added by drunk people without a clue.
Forget core dumps. Catch exceptions and receive exit messages instead.
The HURD does suck, and maybe you should wonder why it does.
The fact is, microkernels are a fraud,
and the HURD, by embodying the advertised model,
is both the victim and the accomplice of this fraud.
Conceptually, microkernels are an abstraction inversion: they force you to hand-implement run-time modularity using a non-modular low-level language, instead of auto-implementing modularity by compiling a modular high-level language into non-modular binary
(see: SPIN, Fox, ML/OS, Squeak, and more).
Modularity is a source-level concept.
Enforcing it at the binary level is DUMB and EVIL.
Binary level should be efficient.
Linux got it right (as far as a C kernel can).
If you want dynamically reconfigurable kernels,
don't bother with HURD and microkernels,
they do not provide any specific advantage for that that "monolithic" kernels don't have. If you really want dynamism, use dynamic languages (LISP, Smalltalk) or at least modular
languages (Modula-3, SML, OCaml), not C.
BTW, VSTa is a free software microkernel that has actually worked for years, yet never attracted any specific interest:
who cares how it works underneath?
What matters is the high-level features it actually provides.
In practice, nobody cares about the puny features provided by microkernels.
I am sick of Netscape 4 and 6, so your post prompted me to revive Netscape 3, which indeed does most of the work, has all the goodies you remind us, doesn't have that braindead preferences menu, and is incredibly fast on my Athlon (whereas Mozilla is dog slow).
Now the biggest problem with NS3 is lack of PNG inline-image support under Linux. There used to be a plugin, but it's no more available. Has anyone a binary copy? It looks like the sources are available somewhere, but recompiling them would require the reconstitution of a complete libc5 compile chain with many libraries: not an impossible task, but no small feat. Hum. Can anyone help?
Meanwhile, just a tip to prevent these nasty interferences between Netscape 3 and 4: edit your netscape 3 binary with emacs, and search&replace
(ESC %) the string netscape with n3tscape. There you are. Don't forget to update your.Xdefaults
accordingly.
"No, sir, we didn't pay no salary to these
free software authors; instead, we paid some
royalty fees so that they accept to grant us
a specific license to use their software under
the industry-standard Microsoft EULA, instead
of just the no-good-nik GNU GPL that it was
otherwise available under."
The MPAA, the RIAA, and other intellectual property lobbies,
are engaged in legal litigation, with the argument that they
will do anything to defend their profits, and consider anyone
who decreases these profits as an enemy, against whom government
must defend them.
Now, the Evil premise in there is that anyone is entitled profits
to begin with: who owes them any profit?
If these industries are entitled the use of governmental force
to keep or increase their profits, then so are customers!
Customers have an interest in keeping and increasing the amount of cheap
or free music, movie, information, etc, available to the public at large.
Thus, the obvious move is to launch a class action suit as a counter-action,
with every single real or potential customer of music, movie theater ticket,
etc, sueing these industries for damages. Every single cent that was
overcharged because of current monopolies can be claimed back as damage.
Multiply $1000 of damages plus interest by 500 000 000 viewers worldwide,
and destroy the robbers.
There has grown up in the minds of certain groups in this country the notion
that because a man or a corporation has made a profit out of the public for a
number of years, the government and the courts are charged with the duty of
guaranteeing such profit in the future, even in the face of changing
circumstances and contrary public interest. This strange doctrine is not
supported by statute nor common law. Neither individuals nor corporations have
any right to come into court and ask that the clock of history be stopped, or
turned back, for their private benefit. That is all.
Slashdot Mirror
Such machines can only yield a fraction of the energy it steals from the car, and the car is itself not very efficient in its use of energy. Such machines are a disaster both in economic and ecological terms -- they increase the waste in fossil energy, cost a lot to install, and yield but a fraction of what they destroy.
I'm sure something as stupid will be loved by all the government executives in the world: something inefficient and counterproductive, but that *looks* like it's doing some good, and helps rob people without their noticing -- my, that's government at its best!
does Friend Computer run? Is it Open Source? Is it based on code from Windows or Linux or MacOS or...
OK, I'll be heading to the nearest termination center. Though, ahem, could you give me the address of said center, or is it also classified above my security clearance? Nevermind, I didn't ask this quest<PROCESS TERMINATED>
Use OpenVPN instead - a breeze to install, secure, interoperable, etc.
The best tools to build parsers and manipulate parsed syntax trees are functional languages, such as OCaml (with its streams parsers, camlp4, ocamllex/ocamlyacc, etc.), or SML, Haskell, etc.
Of course, if you were a LISPer, you'd know that although you have lots of well-known tools to build new parsers, such as Meta or Zebu, the best thing to do about a parser is not to write it, but rather to reuse the builtin extensible universal parser, READ, and its extensible universal unparser, WRITE.
If you spend most of your time writing parsers, you're not just using the wrong tools, you're also using the wrong approach.
Just my .2 mg of e-gold worth...
I have built a router out of a P75 (oc'ed to 90 MHz!), but I recently lost its IBM harddrive. When I opened the case, I it was full of an inches-high structure of dirt. Most probably, the bad ventilation of the case caused the dust to accumulate which in turn prevented heat circulation and contributed to overheat the fragile drive.
The morale of the story is twofold:
Of course a smart card is useful only if it does some crypto (otherwise it is but junk). But that does not suffice to guarantee security, and it is utterly stupid to pretend that "all crypto could be done on the smart card".
For instance, only whole-system security can guarantee the WYSIWYS property (What You See Is What You Sign) -- something essential for any legally binding signature: the security of the workstation where the user signs stuff is thus of primary importance; don't run any unaudited or untrusted software on it. Also, you'll still want to double the card security with normal password security; they don't fight the same kind of attacks, and the combination thus raises the security considerably.
Additionally, you might require a central (but replicated) server to stamp any document before it is considered binding, so as to be able to keep track of what your company has signed. Otherwise, you might wake up with bad surprises, the day you learn you signed for millions worth of debt.
Finally, you must provide customers a trusted way to check whether a certificate is signed, and what it really means --- the fact that the other contracting party may trust you is the whole point of a digital signature; if it does not participate in creating this contractual value, your digital certificate is not worth the electromagnetic field it is encoded with. Oh, and so that your customers may give any value to the contracts you signed, they must understand it, so you'll want to include within the signed contracts a short and effective description of the contract, and not just a bookful of legalese (lawyers are more efficient than cryptographers at making a text unreadable).
Another .002 mg of gold worth.
The problem is that you can't keep those keys in a secure server watched 24/24 by armed guards --- you must hand them out (or hand a key to a key to a key) to the actual humans who will have to use them, and there you have a weak link in your security chain: how can you prove that the key can't be stolen? Or are you willing to be liable for anything signed with a stolen key?
Things can be enhanced by having some kind of physical key (a credit card or better, one of those small round things that you put in an actual keyring) attached to every person, to unlock his keys; usable only with his personal password at a secure desk within the walls of the company. Usual protection against Tempest are useful, to prevent anyone from stealing your passwords, etc.
If you find a cost effective way to manage digital signatures, you might find that you can make an awful lot of money selling the process to other companies, as part of streamlining their internal IT processes.
Just my .002 mg of gold worth.
Politician - here's the career of the past, present and future!
Now just you try to contact your government and tell them you want to end your subscription to their service!
Please stop thinking in terms of inferior languages like C and Java as if they were the be-all end-all of computing.
This is not the fact being denied. The fact being denied is that runtime protection barriers would be a sensible way to limit privileges to begin with. Development-time and compile-time protection methods are far more efficient:
The basic premise behind a microkernel is that device drivers will be black box proprietary binary code from untrusted third parties, hence require clumsy run-time protection. This hypothesis has been invalidated in practice for proprietary systems, and doesn't even make sense in theory for free software systems.
There is no need whatsoever for expansive memory protection between modules at runtime. Modularity is great, but at development-time, not runtime. HURD doesn't give you any additional development-time modularity; if anything, it removes it. If you want development-time modularity, drop that stupid C language, and use a modular language, such as Modula-3 (SPIN-OS), SML (Fox, Express), or Erlang (standalone Erlang).
Microkernels were the latest hype in the 1980's for OS development. They've only ever been hype, and it's sad that GNU people waste their time with such a stupid concept, whereas there's so much more to OS design, including lots of proven concepts, that just await to be implemented in free software (who's gonna implement the lost features from Genera? from Eumel?)
Using the C language to implement anything else but the lowest-level layers of a system is plain incompetence, all the more when security is involved. The criterium is simple: if there is ANY use of dynamic allocation, you should use a safe language like OCAML, CommonLISP, Mercury, Perl, Python, etc. [Of course, C may be used when *implementing* the dynamic allocation].
You might not want to join my own TUNES project, that is mostly vapourware at the point; but you'll find there plenty of inspiration as to how the future of computing can be imagined. Then, it's up to you to revive the project, found your own, or evolve some existing project toward something you like better.
And of course, there's no reason why you should be victim of off-by-one bugs. There are already great languages with successful implementations that will rid you of them, and provide features undreamed of by people brainwashed with C/C++/Java. Clean, Common LISP (CMUCL), Erlang, Haskell, Mercury, ML (OCAML, SML/NJ, ML-Kit), Oz (mozart), Scheme (MzScheme), Smalltalk (Squeak), and so many more, are already available, and can enable kinds of hacking impossible with lesser languages.
Just don't you use inferior systems and then complain about the braindeadness. The only obstacle between your dreams and their implementation is YOU.
Hence, I use A=65, B=66, C=67, etc...
I've called this encryption code "ASCII", which stands for "Absolutely Secret Code for Idiocy Interchange".
-- Faré @ TUNES.org
You can have multiple X servers running, one in each virtual terminal. I have a set of scripts that automatically launch a new X server with some minimal twm setting, so as to run applications full screen: view DVI/PS/PDF documents, JPG/GIF pictures, HTML documents with embedded pictures, play games, etc. Very handy when you're in a console switching period and your preferred window manager is the linux kernel's virtual terminal facility.
In case you don't want to roll your own from scratch, I can make my scripts available on request: they work very well for me, although it would require quite a lot of work to package them into a RPM, and you'll have to dig the CVS for versions that used to work with older X setups.
Unix sucks so much.
-- Faré @ TUNES.org
- OCaml is multithreaded (linuxthreads was born as a way to get it to work on linux), although
a single program won't take advantage of a multiprocessor. Core dump is impossible using
its static strong typing, and the optimizing
native-code compiler provides with great performance.
- JOCaml is an extension of OCaml based on the
Join-Calculus, the latest and greatest paradigm
for distributed programming (can be seen as actor-based programming done right, as based on
a well-understood algebra). Can take advantage not only of multiprocessors, but of processor farms, or any distributed architecture, even heterogeneous architectures. Only bytecode can migrate, native code modules and primitives must be compiled into the servers.
- Erlang is based on a paradigm quite similar to jocaml, but is designed for industrial applicability rather than hacker coolness; it has dynamic typing, a pure functional core (despite the logic programming syntax, it only has matching, not unification), enriched with explicit asynchronous communication primitives, and an implementation
that every phone call you make depends on, if you
use British Telecom. If you need tens of thousands of threads and/or lots of nodes, this is what you need.
- There is also Mozart,
an distributed implementation of Oz, a real logic programming language (has unification).
- Haskell and Mercury also have extensions for concurrent and distributed programming in the works, but I admit I don't know how usable they are for real programming.
Use real languages with a nicely designed concurrent programming algebra, not fake languages that were never designed to begin with, and had a kluge of concurrent primitives added by drunk people without a clue. Forget core dumps. Catch exceptions and receive exit messages instead.-- Faré @ TUNES.org
The fact is, microkernels are a fraud , and the HURD, by embodying the advertised model, is both the victim and the accomplice of this fraud.
Conceptually, microkernels are an abstraction inversion: they force you to hand-implement run-time modularity using a non-modular low-level language, instead of auto-implementing modularity by compiling a modular high-level language into non-modular binary (see: SPIN, Fox, ML/OS, Squeak, and more).
Modularity is a source-level concept. Enforcing it at the binary level is DUMB and EVIL. Binary level should be efficient. Linux got it right (as far as a C kernel can).
If you want dynamically reconfigurable kernels, don't bother with HURD and microkernels, they do not provide any specific advantage for that that "monolithic" kernels don't have. If you really want dynamism, use dynamic languages (LISP, Smalltalk) or at least modular languages (Modula-3, SML, OCaml), not C.
BTW, VSTa is a free software microkernel that has actually worked for years, yet never attracted any specific interest: who cares how it works underneath? What matters is the high-level features it actually provides. In practice, nobody cares about the puny features provided by microkernels.
-- Faré @ TUNES.org
Now the biggest problem with NS3 is lack of PNG inline-image support under Linux. There used to be a plugin, but it's no more available. Has anyone a binary copy? It looks like the sources are available somewhere, but recompiling them would require the reconstitution of a complete libc5 compile chain with many libraries: not an impossible task, but no small feat. Hum. Can anyone help?
Meanwhile, just a tip to prevent these nasty interferences between Netscape 3 and 4: edit your netscape 3 binary with emacs, and search&replace (ESC %) the string netscape with n3tscape. There you are. Don't forget to update your .Xdefaults
accordingly.
-- Faré @ TUNES.org
-- Faré @ TUNES.org
Uh? Who are you kidding? Looks like you have been smoking something fairly strong, lately (such as political propanganda).
"Non-profit organization": this term is such an oxymoron, anyway! As if any organization could last without somehow benefitting its members!
The whole DNS monopoly is a huge racket on the internet, anyway.
-- Faré @ TUNES.org
Now, the Evil premise in there is that anyone is entitled profits to begin with: who owes them any profit? If these industries are entitled the use of governmental force to keep or increase their profits, then so are customers! Customers have an interest in keeping and increasing the amount of cheap or free music, movie, information, etc, available to the public at large. Thus, the obvious move is to launch a class action suit as a counter-action, with every single real or potential customer of music, movie theater ticket, etc, sueing these industries for damages. Every single cent that was overcharged because of current monopolies can be claimed back as damage. Multiply $1000 of damages plus interest by 500 000 000 viewers worldwide, and destroy the robbers.
-- Faré @ TUNES.org