Does this mean it will now be illegal to use a secure system? Having any type of security/virus protection will be circumvention of law-enforcing software.
And what happens if this "happens" to get installed on a foreign government's computer? Can we say "espionage"?
I will do this sometimes for code that is intended for short-term, internal-only use, as I can often save quite a bit of valuable time.
And what happens when a suit decides that what you have is just what the company needs for its next product? No, we don't have time to change it. Just ship it as it is.
Any code that is written as job security is inherintly a bad thing. Reducing the maintainability of the product to the point that only you can work with it prevents errors from being caught. As we've all learned, the person least likely to find an error is the person who made it. When that person is the only one who can possibly find the error...well, you do the math.
This could be useful, for multi-tier apps, or for various parts of app development.
For multi-tier apps, you could have a domain-specific language at the back end. This interfaces with C, which is the main server app. Then various languages come above that, for various views. For example, a web interface could be in PHP or Perl, an interactive interface in Java or C++, etc.
The project I'm working on is mostly C. The build system, however, is mostly Perl. The two parts of the system are cleanly separated, and there's very little reason for them to talk to each other (although the build system does pass build-time configuration to the app).
Instead of running separate processes, how about using the bindings that the languages have for each other? Most languages can bind with C; all you have to do is use that capability of the languages, rather than worry about forking and pipes.
As a user, there appears to be no difference. The kernel maintainers see the difference.
CML is a way for the kernel hackers to tell the config system what options you see when you type "make xconfig".
The kernel-hacker writes some CML code, which he then compiles into a config file. Then, you run xconfig, menuconfig, advent, or any other frontend that gets created, and you have a configured tree. And when the kernel-hacker adds a feature, there's less chance that he'll break configuration dependencies.
it would be a good project to try and extend ESR's idea to formalise config files for compiled packages.
OK, so this thing reads a menu-definition file and spits out--what? A Makefile? An.c file? Something else?
What I'm thinking is to have it read your menu-def file, and spit out a config-file creater and a parser.
For example, you tell it you have a configuration option "FOO", which is a boolean value, and "BAR", which is a string. These are put in the menu somewhere. You run this through the config-generation app, which spits out two modules: one to create a config file, one to read it.
Now you create the config file using whatever front-end you want (standard menu, graphical, Zork, whatever). Then in the app, you say something like getconfig("BAR"). The library is able to validate the entry (it knows that "BAR" is a string), and set a default (also from the generation script).
Is this what CML does, or am I completely mistaken?
The other examples posted on ESR's page are for kernel-oriented projects. How hard is it to stick this in another project? Something slightly smaller-scale than the kernel?
Also, this seems to only be concerned with compilation-time configuration. Although pre-compilation config is important, how hard is it to adapt this to work after compilation? If another app could use this configuration engine after it's been compiled and distributed, it may make it easier to customize pre-compiled packages (RPMs, DEBs, etc).
After all anthrax doesn't kill people, people kill people
Actually, since it is possible to get anthrax naturally (farmers get it from their animals), this is a case where that tired, old cliche doesn't quite work.
No. You don't buy to underwrite a failing business. However, you also shouldn't pull out as soon as it looks like it might go bad. That's how stock crashes happen.
If I was teaching a course, though, I would disobey C's precedence rules and implement sensible ones instead.
If you have a language that's "more-or-less C", follow C's rules. If you teach the students a broken set of precedence rules, you're not doing them any favours - you'll break any program that they make following your precedence rules.
Or [how about this] get the compiler to throw out any expressions whose bracketing makes operator precedence important? It's bad style to rely on C operator precedence, and here you have a perfect opportunity to teach that.
This, I agree with. I've maintained code that relies on precedence. When you've been doing it for a few hours, they get screwed up in your head. Nice, obvious parens make everything so much easier, I sometimes wonder why it wasn't a requirement in the first place.
"How about BeOS, *nix, Amiga, QNX, etc?," I am asked. Those who are comfortable using these operating systems need no such guide as this; clean, well-made software is the rule rather than the exception
I don't know about BeOS and Amiga. You can get quite a bit in a small space with QNX - after all, that's what it's designed for. As for Linux, I can't fit much more than a firewall or a recovery kit on a single floppy, so I don't know what he's tripping on.
In some parts of the Middel East, the luggage is lined up next to the aircraft, and each passenger is required to identify their suitcase, etc. Any bags not matched to passengers after boarding are detonated on the spot.
That must be really annoying if you and your baggage manage to get separated. Or do their airlines never send luggage to the wrong place?
What we need isn't a technical solution. What we need isn't government intervention. What we need is consumer education. We know what's wrong with XP. Apparently EPIC knows (although the original article is slashdotted). However, the average consumer doesn't. If they knew the problems and alternatives, they could make an informed decision.on whether to use Windows, Mac, Linux, BSD, etc.
As for Richard Garriott's approval, that's like getting permission from Toto to remake The Wizard of Oz.
From a purely legal standpoint, that may be.true. But how do they get off comparing permission from the world's creator to permission from the main character's "little dog"? I mean, they have permission of the guy who made the damn game. Why should they need more?
When I was in college, I did both. I had my laptop for taking text notes (the majority), and pencil and paper for taking down diagrams. I could also save time by downloading the instructors' class notes from their webpages, and only taking down the notes where they added information.
Staph and E.Coli exist in the regular human body. Problems exist when their counts get unbalanced. For example, you eat some tainted eggs and your E.Coli levels go through the roof. If the system just showed numbers like this, you would have alot of hypochondriacs worried about nothing.
However, your ebola count would be a problem. That 0.035% ebola count would probably kill you. Unless, of course, you were lucky enough to get the Reston strain of it, which so far has shown to be non-pathogenic in humans (ie we can't get it).
Slashdot Mirror
How 'bout we just cut out all the steps in between - make lawyers illegal.
Does this mean it will now be illegal to use a secure system? Having any type of security/virus protection will be circumvention of law-enforcing software.
And what happens if this "happens" to get installed on a foreign government's computer? Can we say "espionage"?
And what happens when a suit decides that what you have is just what the company needs for its next product? No, we don't have time to change it. Just ship it as it is.
Any code that is written as job security is inherintly a bad thing. Reducing the maintainability of the product to the point that only you can work with it prevents errors from being caught. As we've all learned, the person least likely to find an error is the person who made it. When that person is the only one who can possibly find the error...well, you do the math.
This could be useful, for multi-tier apps, or for various parts of app development.
For multi-tier apps, you could have a domain-specific language at the back end. This interfaces with C, which is the main server app. Then various languages come above that, for various views. For example, a web interface could be in PHP or Perl, an interactive interface in Java or C++, etc.
The project I'm working on is mostly C. The build system, however, is mostly Perl. The two parts of the system are cleanly separated, and there's very little reason for them to talk to each other (although the build system does pass build-time configuration to the app).
Instead of running separate processes, how about using the bindings that the languages have for each other? Most languages can bind with C; all you have to do is use that capability of the languages, rather than worry about forking and pipes.
As a user, there appears to be no difference. The kernel maintainers see the difference.
CML is a way for the kernel hackers to tell the config system what options you see when you type "make xconfig".
The kernel-hacker writes some CML code, which he then compiles into a config file. Then, you run xconfig, menuconfig, advent, or any other frontend that gets created, and you have a configured tree. And when the kernel-hacker adds a feature, there's less chance that he'll break configuration dependencies.
OK, so this thing reads a menu-definition file and spits out--what? A Makefile? An
What I'm thinking is to have it read your menu-def file, and spit out a config-file creater and a parser.
For example, you tell it you have a configuration option "FOO", which is a boolean value, and "BAR", which is a string. These are put in the menu somewhere. You run this through the config-generation app, which spits out two modules: one to create a config file, one to read it.
Now you create the config file using whatever front-end you want (standard menu, graphical, Zork, whatever). Then in the app, you say something like getconfig("BAR"). The library is able to validate the entry (it knows that "BAR" is a string), and set a default (also from the generation script).
Is this what CML does, or am I completely mistaken?
The other examples posted on ESR's page are for kernel-oriented projects. How hard is it to stick this in another project? Something slightly smaller-scale than the kernel?
Also, this seems to only be concerned with compilation-time configuration. Although pre-compilation config is important, how hard is it to adapt this to work after compilation? If another app could use this configuration engine after it's been compiled and distributed, it may make it easier to customize pre-compiled packages (RPMs, DEBs, etc).
Actually, since it is possible to get anthrax naturally (farmers get it from their animals), this is a case where that tired, old cliche doesn't quite work.
No. You don't buy to underwrite a failing business. However, you also shouldn't pull out as soon as it looks like it might go bad. That's how stock crashes happen.
Sounds really intelligent there! The company's going to fail, so sell off all your stock so it'll fail sooner! Self-serving people make me sick.
What will we call the digits? Click here to find out:
http://www.schlockmercenary.com/d/20001226.html
After he left the Enterprise, Crusher was Borged!
If you have a language that's "more-or-less C", follow C's rules. If you teach the students a broken set of precedence rules, you're not doing them any favours - you'll break any program that they make following your precedence rules.
This, I agree with. I've maintained code that relies on precedence. When you've been doing it for a few hours, they get screwed up in your head. Nice, obvious parens make everything so much easier, I sometimes wonder why it wasn't a requirement in the first place.
That's of very little use if you can't get in. I get the same message on the feedback page as I did on the front page. (Using Konqueror).
When you have all the source, you can take out what you don't want. Have you ever tried that with a binary?
I don't know about BeOS and Amiga. You can get quite a bit in a small space with QNX - after all, that's what it's designed for. As for Linux, I can't fit much more than a firewall or a recovery kit on a single floppy, so I don't know what he's tripping on.
That must be really annoying if you and your baggage manage to get separated. Or do their airlines never send luggage to the wrong place?
What we need isn't a technical solution. What we need isn't government intervention. What we need is consumer education. We know what's wrong with XP. Apparently EPIC knows (although the original article is slashdotted). However, the average consumer doesn't. If they knew the problems and alternatives, they could make an informed decision.on whether to use Windows, Mac, Linux, BSD, etc.
From a purely legal standpoint, that may be.true. But how do they get off comparing permission from the world's creator to permission from the main character's "little dog"? I mean, they have permission of the guy who made the damn game. Why should they need more?
When I was in college, I did both. I had my laptop for taking text notes (the majority), and pencil and paper for taking down diagrams. I could also save time by downloading the instructors' class notes from their webpages, and only taking down the notes where they added information.
However, your ebola count would be a problem. That 0.035% ebola count would probably kill you. Unless, of course, you were lucky enough to get the Reston strain of it, which so far has shown to be non-pathogenic in humans (ie we can't get it).
Does that mean it isn't illegal to DDOS a website by repeatedly downloading its front page? After all, the front page is there for people to view.
You already do. It's called your keyboard.