Remember that you already paid for the commercial TV crap every time you buy something in your local supermarket. All prices of consumer goods are marked up to pay for the commercials shown on TV, that in turn are paying for the programmes. So you have been paying all the time, even when you don't have a TV.
But what is your alternative? Pay no fee, and have commercial TV instead? That means that you pay for TV even when you don't have a TV set! Is that so much better?
You may think that "the American way" of commercial TV is more fair than the traditional European system of a TV ownership tax/fee, but of course it isn't. You pay for your TV through the consumption of goods, which have a markup for the advertisement of these goods, which pays for TV stations. This means you even pay for TV when you never watch it. The European system at least taxes only those that actually have a TV.
Of course in Europe, where people beleive that everyting the USA does must be good, we now have two parallel systems: some channels paid from taxes or fees, and other channels paid for by advertising. (with the associated focus on quantity instead of quality)
But Windows NTFS is much closer to that goal than the classic Unix filesystems! Apparently "the user does not want this", or else Microsoft would have put more emphasis on this feature?
Because this bug was about erasing a collection of downloaded files that was kept in a directory used as the default download directory. When using chroot that directory would have to be under the chroot point and thus would have been erased just as well. You can say "but I would have moved the files out of that directory into a permanently safe place", but the bugreporter should have done that (and will probably do that) anyway. So, chroot does not make any difference in this case.
>Has no one else ever started driving with the emergency brake on ?
The deceleration spec for the emergency brake is about 1/5th of the normal brake.
>we haven't started taking the momentum of a huge piece of steel into account yet
The reason why the law does not state a force but a deceleration is exactly that: the heavier the car, the better the brakes must be to meet the spec.
It is not very relevant to discuss the forces needed to decelerate the mass of the car, as exactly the same forces are needed to accelerate it. A heavier car is harder to brake, but also harder to accelerate.
My car is light according to American standards (988 kg) but has a reasonable power/weight ratio (110 hp engine). Still the brakes are much, much more powerful than the engine. I would love it when it could accelerate as fast as it brakes:-)
The deceleration of the brakes is much more than the acceleration by the engine. In a typical car, about twice as much. So if they cannot bring you to a full stop once with the engine at full power, they probably will not be able to stop you twice at normal conditions either.
The minimum deceleration is 5.2 m/s^2 which means it would stop from 100 km/h (28 m/s) in 5.3 seconds. A typical car decelerates 7 m/s so it would stop in 4 seconds from that speed. A fast roadcar accelerates to 100 km/h in 9-10 seconds, or only about 3-4 m/s^2.
>and breaking a floored car doing 50 does - absolutely nothing
As explained in many other followups, this is absolutely nonsense. A car in normal operating condition should brake much harder than it accelerates. Try it the next time you drive the car: time how long it takes to accelerate to 50, then time how long it takes to stop from there.
Also don't forget that MS has been stealing from the OpenSource community. I significant portion of systems running Linux has likely been bought with a MS operating system pre-installed and its license paid. Efforts to refund that money have always been frustrated by MS and its OEMs.
1. At the time I wrote this, the PHP module could read data from LDAP fine, but it would just segfault apache at any attempt to modify anything. I have not tried that way recently, probably it has been fixed. In those days Net::LDAP was too slow for use in a cgi-bin, because of the time required to load and initialize. Probably not an issue anymore either.
2. The step between provides the opportunity to merge data from different sources and cross-check it. E.g. we nightly read account data from the Windows domain controller and the Linux passwd file, put that in some tables in MySQL, and combine the data from those tables with the manually-entered data to generetate the.ldif file.
When a good tool would exist, it would probably be possible to do those extra actions in a separate nightly job and update the LDAP database from two places. But as it is now, it is easier via MySQL.
You are right about the schema flexibility. That is why I wrote the tool should be configurable. There should be some configuration file describing the layout of the panel (fixed text and fields), and something that maps the fields to the attributes in LDAP. The mapping should allow things like validation, translation (lower-upper or upper-lower case, for example) and concatenation of fields into attributes. A tool written in Perl that allows writing the mapping as an external Perl module is probably best.
From what I see in the screenshot, it is just another "regedit-like LDAP explorer". This is NOT what I need. And not what the average user needs, I think.
What I need is a program that displays complete panels with all information about a certain object (maybe on more than one tab) that allows editing on the object level.
Just consider a simple, very typical case: a new employee joined the company, you want to add a person record. Do you want to type a DN, add the record, then one by one open all kinds of attributes, and enter data for them? NO. What a normal user would want is something like the "User manager" found in Windows. Select the action "add person", get a panel, enter data like fullname, username, telephone number, location etc. and click ADD. Insert all data in the LDAP server in one go.
Is that really too much to ask?? All the opensource LDAP editors I have seen work on that attribute level instead of the more sensible record level.
Of course there is even more: not only I would want to enter data for a person at once, but also I would want to enter data once and put it in more than one attribute. Controllable by some configuration like a template.
Example: you enter Firstname, Middle, Lastname in 3 fields. Attributes inserted in the LDAP record: Firstname, Middle, Lastname but also a "cn" consisting of the above three. Or: you enter the user-id, and additionally a "mail" attribute is automatically added as @.
This is what you need to have an LDAP directory operating in a company, and have it maintained by ordinary helpdesk personnel or a secretary, instead of an LDAP hacker. The lack of such a tool is a real problem for LDAP usage in an opensource environment.
What I did at work is make some PHP scripts that put up HTML forms that have the above functionality, store the data in a MySQL database, and nightly run a job that reads the database, writes a.ldif file, and loads this into OpenLDAP.
Far from optimal, to say the least. And as it is very specific for our environment, also not distributable as the solution for everyone. We need something like this, but configurable.
>NORTH-SOUTH is the direction of the road. In french this is referred to from south to north, but is the same thing.
No. It says "sens SUD-NORTH" which means "direction SOUTH-NORTH" and refers to the side of the road the accident happened: from SOUTH (Paris) to NORTH (Lille). So your NORTH-SOUTH is just a wrong translation, not "the same thing".
The server works. Sure it requires some study of the documentation and some trial and error, but I have been running the OpenLDAP server at work for years, and it never caused a problem after the initial configuration.
What I think is a real problem: the lack of a user-friendly tool to maintain the database. Some open source tools exist but they are too low-level. E.g. they operate on the level of "add record" and "add attribute".
What you need is a tool that can be user-configured, and comes with panels for typical configurations (that can be altered). You want to have panels for "maintain a person record" or "maintain an organizational unit record" that present input fields at the level a helpdesk person can understand (like "username", "full name", "telephone number" etc) and that get validated as whole and updated in the LDAP server when the panel is submitted.
I have not yet seen such a tool in the opensource LDAP world.
OFDM may not be new as a technology, but what is "new" is the possibility of implementing it in consumer-grade devices, made possible by the more and more powerful and ever cheaper DSP devices. Of course not "new" in the sense that it should appear in a news article today, but practical use of OFDM at megabit rates has only been possible for a couple of years.
You will find that only people with negative experiences write such reviews. We have been running W2000 SP4 on all of our (200+) desktops for a long time, and no SP-related problems at all.
Would it really work? Wouldn't the FTP requests be treated as "done by Internet Explorer" when some exploit inside IE (or a library used by IE) tries to do an FTP? Presumably, Zonealarm does allow FTP from IE. If not, the next generation of this virus could use a HTTP request.
This page refers to a download location for an updated gdiplus.dll, but the extracted file is dated 04-05-2004. Is that really the fixed version? Did Microsoft know about this problem for so long?
There are some apps that can be installed driven by a.ini file or other unattended install, but often it is difficult to get information about it. We use it when possible. E.g. for Office, Mozilla, etc.
When not possible, we use a KIXtart script. It can start a program (in this case, usually SETUP.EXE), then watch which dialogs appear on the screen and send keypresses to it. It can also insert delays, etc. Usually a couple of Alt-N ("Next") and/or Enter keys will do the job.
Ok but this is the same in a country without this system (assuming they have commercial TV and the commercials are paid for by the consumers)
I don't think that is the reason. It must be very easy to check if you subscribed to a cable service or Sky.
Remember that you already paid for the commercial TV crap every time you buy something in your local supermarket. All prices of consumer goods are marked up to pay for the commercials shown on TV, that in turn are paying for the programmes.
So you have been paying all the time, even when you don't have a TV.
But what is your alternative?
Pay no fee, and have commercial TV instead?
That means that you pay for TV even when you don't have a TV set!
Is that so much better?
You may think that "the American way" of commercial TV is more fair than the traditional European system of a TV ownership tax/fee, but of course it isn't.
You pay for your TV through the consumption of goods, which have a markup for the advertisement of these goods, which pays for TV stations. This means you even pay for TV when you never watch it.
The European system at least taxes only those that actually have a TV.
Of course in Europe, where people beleive that everyting the USA does must be good, we now have two parallel systems: some channels paid from taxes or fees, and other channels paid for by advertising. (with the associated focus on quantity instead of quality)
But Windows NTFS is much closer to that goal than the classic Unix filesystems!
Apparently "the user does not want this", or else Microsoft would have put more emphasis on this feature?
Because this bug was about erasing a collection of downloaded files that was kept in a directory used as the default download directory.
When using chroot that directory would have to be under the chroot point and thus would have been erased just as well.
You can say "but I would have moved the files out of that directory into a permanently safe place", but the bugreporter should have done that (and will probably do that) anyway.
So, chroot does not make any difference in this case.
> Running Mozilla or Firefox in a chroot environment would greatly enhance security
Of course it would not have helped in this case.
It is not a bug in Mozilla. It is a bug in Firefox.
Please don't confuse Mozilla users with security bugs that are not in their browser.
>Has no one else ever started driving with the emergency brake on ?
:-)
The deceleration spec for the emergency brake is about 1/5th of the normal brake.
>we haven't started taking the momentum of a huge piece of steel into account yet
The reason why the law does not state a force but a deceleration is exactly that: the heavier the car, the better the brakes must be to meet the spec.
It is not very relevant to discuss the forces needed to decelerate the mass of the car, as exactly the same forces are needed to accelerate it. A heavier car is harder to brake, but also harder to accelerate.
My car is light according to American standards (988 kg) but has a reasonable power/weight ratio (110 hp engine). Still the brakes are much, much more powerful than the engine.
I would love it when it could accelerate as fast as it brakes
The deceleration of the brakes is much more than the acceleration by the engine. In a typical car, about twice as much. So if they cannot bring you to a full stop once with the engine at full power, they probably will not be able to stop you twice at normal conditions either.
The car would probably not be street legal here.
The minimum deceleration is 5.2 m/s^2 which means it would stop from 100 km/h (28 m/s) in 5.3 seconds. A typical car decelerates 7 m/s so it would stop in 4 seconds from that speed.
A fast roadcar accelerates to 100 km/h in 9-10 seconds, or only about 3-4 m/s^2.
>and breaking a floored car doing 50 does - absolutely nothing
As explained in many other followups, this is absolutely nonsense.
A car in normal operating condition should brake much harder than it accelerates. Try it the next time you drive the car: time how long it takes to accelerate to 50, then time how long it takes to stop from there.
Also don't forget that MS has been stealing from the OpenSource community. I significant portion of systems running Linux has likely been bought with a MS operating system pre-installed and its license paid. Efforts to refund that money have always been frustrated by MS and its OEMs.
Yes, this is much more like it.
The reasons for this are twofold:
.ldif file.
1. At the time I wrote this, the PHP module could read data from LDAP fine, but it would just segfault apache at any attempt to modify anything.
I have not tried that way recently, probably it has been fixed. In those days Net::LDAP was too slow for use in a cgi-bin, because of the time required to load and initialize. Probably not an issue anymore either.
2. The step between provides the opportunity to merge data from different sources and cross-check it. E.g. we nightly read account data from the Windows domain controller and the Linux passwd file, put that in some tables in MySQL, and combine the data from those tables with the manually-entered data to generetate the
When a good tool would exist, it would probably be possible to do those extra actions in a separate nightly job and update the LDAP database from two places. But as it is now, it is easier via MySQL.
You are right about the schema flexibility. That is why I wrote the tool should be configurable. There should be some configuration file describing the layout of the panel (fixed text and fields), and something that maps the fields to the attributes in LDAP. The mapping should allow things like validation, translation (lower-upper or upper-lower case, for example) and concatenation of fields into attributes.
A tool written in Perl that allows writing the mapping as an external Perl module is probably best.
From what I see in the screenshot, it is just another "regedit-like LDAP explorer".
.ldif file, and loads this into OpenLDAP.
This is NOT what I need. And not what the average user needs, I think.
What I need is a program that displays complete panels with all information about a certain object (maybe on more than one tab) that allows editing on the object level.
Just consider a simple, very typical case: a new employee joined the company, you want to add a person record.
Do you want to type a DN, add the record, then one by one open all kinds of attributes, and enter data for them? NO.
What a normal user would want is something like the "User manager" found in Windows. Select the action "add person", get a panel, enter data like fullname, username, telephone number, location etc. and click ADD. Insert all data in the LDAP server in one go.
Is that really too much to ask?? All the opensource LDAP editors I have seen work on that attribute level instead of the more sensible record level.
Of course there is even more: not only I would want to enter data for a person at once, but also I would want to enter data once and put it in more than one attribute. Controllable by some configuration like a template.
Example: you enter Firstname, Middle, Lastname in 3 fields.
Attributes inserted in the LDAP record: Firstname, Middle, Lastname but also a "cn" consisting of the above three.
Or: you enter the user-id, and additionally a "mail" attribute is automatically added as @.
This is what you need to have an LDAP directory operating in a company, and have it maintained by ordinary helpdesk personnel or a secretary, instead of an LDAP hacker.
The lack of such a tool is a real problem for LDAP usage in an opensource environment.
What I did at work is make some PHP scripts that put up HTML forms that have the above functionality, store the data in a MySQL database, and nightly run a job that reads the database, writes a
Far from optimal, to say the least. And as it is very specific for our environment, also not distributable as the solution for everyone.
We need something like this, but configurable.
>NORTH-SOUTH is the direction of the road. In french this is referred to from south to north, but is the same thing.
No. It says "sens SUD-NORTH" which means "direction SOUTH-NORTH" and refers to the side of the road the accident happened: from SOUTH (Paris) to NORTH (Lille).
So your NORTH-SOUTH is just a wrong translation, not "the same thing".
The server works. Sure it requires some study of the documentation and some trial and error, but I have been running the OpenLDAP server at work for years, and it never caused a problem after the initial configuration.
What I think is a real problem: the lack of a user-friendly tool to maintain the database.
Some open source tools exist but they are too low-level. E.g. they operate on the level of "add record" and "add attribute".
What you need is a tool that can be user-configured, and comes with panels for typical configurations (that can be altered).
You want to have panels for "maintain a person record" or "maintain an organizational unit record" that present input fields at the level a helpdesk person can understand (like "username", "full name", "telephone number" etc) and that get validated as whole and updated in the LDAP server when the panel is submitted.
I have not yet seen such a tool in the opensource LDAP world.
OFDM may not be new as a technology, but what is "new" is the possibility of implementing it in consumer-grade devices, made possible by the more and more powerful and ever cheaper DSP devices.
Of course not "new" in the sense that it should appear in a news article today, but practical use of OFDM at megabit rates has only been possible for a couple of years.
>"Microsoft has said it will remove Media Player from Window, if ordered by the EU this week.
Of course. The other option would be to stop selling Windows in the EU. Who would have expected that?
You will find that only people with negative experiences write such reviews.
We have been running W2000 SP4 on all of our (200+) desktops for a long time, and no SP-related problems at all.
Would it really work?
Wouldn't the FTP requests be treated as "done by Internet Explorer" when some exploit inside IE (or a library used by IE) tries to do an FTP?
Presumably, Zonealarm does allow FTP from IE.
If not, the next generation of this virus could use a HTTP request.
This page refers to a download location for an updated gdiplus.dll, but the extracted file is dated 04-05-2004.
Is that really the fixed version? Did Microsoft know about this problem for so long?
There are some apps that can be installed driven by a .ini file or other unattended install, but often it is difficult to get information about it.
We use it when possible. E.g. for Office, Mozilla, etc.
When not possible, we use a KIXtart script. It can start a program (in this case, usually SETUP.EXE), then watch which dialogs appear on the screen and send keypresses to it. It can also insert delays, etc.
Usually a couple of Alt-N ("Next") and/or Enter keys will do the job.
The same is possible with VBscript or Auto-It.