You would still have two conversions, one from mains to 12v and another from 12v to what you need. That would include 12v. The battery voltage is too uncertain to use as 12v supply for the computer.
So, while running on battery the efficiency would be better (only the second converter would be running), but when running on the mains it would be worse. It would be like an online UPS. With an offline UPS (the one that switches over when the power fails), the efficiency would be better during powered mode.
The best probably is to standardize on 48v when you need UPS service. Have the mains converted to 48v at a central place in your house, include 48v batteries, and use 48v supplies in your equipment. (a supply that has 48vdc input).
This equipment is available, but because of the limited volume and more professional use, it costs way more than a standard supply and normal UPS.
I have seen this happen with other Windows updates (hotfixes) as well! When you run VMware, it by default creates a drive for sharing information between sessions. I think it is called Z: by default. The root directory of this drive is not writable, it contains folders that are writable. Many updates fail when this condition is present.
I think the updater does a check for writability only via the ACLs, and fails to notice a drive that is non-writable by design, but does not advertise this via the ACL. (of course it recognizes CD-ROM drives as non-writable)
What I want to state is that the average price of the average computer has not dropped that much. It has dropped a bit, but not that much as when you look at price-per-memory-byte etc.
Sure I have spent lots of money on parts that are cheap now, like $400 for a floppydrive or $1000 for a 5MB diskdrive.
Sure when you compare byte-for-byte, the price has dropped dramatically over 20 years. But when you compare price of a typical user's system, is the difference really that much?
Today a typical office desktop machine would be around 1000 euro (or US$). That is also what I paid for my first computer in 1980. Of course it had 16K instead of 512M of RAM, a tape recorder instead of a 120GB harddisk drive, a 2 MHz Z-80 processor instead of a 3 GHz Pentium 4, but the users of that time bought it for the same purpose as the users of today.
So while you get a lot more for your money today, it is not like the price of a desktop system dropped from 'about the same as a car' to 'about the same as a candybar'.
My experience is that it does not matter to where you outsource it. Any job outsourced to another company can result in bad quality code. Remember that every company will tell you how good the quality of their programmers is, how good their methodology is, etc. But in the end they just allocate a bunch of programmers to your job, and every time a new (= always more important) job comes in, the best people are moved to there and a new load of trainees continues on your work.
This can happen when you outsource to India, but it may just as well happen when you outsource to a reputable company in your own country.
Of course it is easy, especially in the intrusive way it is done in VMS. It simply gives out new file numbers every time and shows the users all the versions of the file that are there. A simple patch would make that available in Linux (could be a little trickier when links and symlinks are considered as well).
Already better is the way it is done in Novell Netware. The old versions are normally not visible, the space they occupy is automatically released when the disk runs out of capacity, etc. The user normally does not see the versioning going on, but can still access it when required.
However, a really useful feature (especially for textfiles) would be automatic versioning by something like RCS or CVS. Those systems do not store the full files for every change, but only the diffs. That allows to store many more versions without running out of space, and to do more intelligent things like "remove the changes that occurred between version 11 and 12 from my current version 20 file and make that version 21 (current)".
In fact I use a script on many systems that I administer, that uses RCS for such a versioning. I dislike the "checkout, modify, checkin" paradigm that underlies RCS (and that makes it unusable for versioning files that are in actual use, like configuration files in/etc) but with this extra script that I run nightly from cron I keep al changes that have occured during a day in an RCS archive for each file on the system for which an RCS archive exists in an RCS/ subdirectory below the file.
Having this as a builtin in the system would be a bonus, but as often it can be sort of simulated with an addon script.
One could conclude that either: - this feature was not considered important by users and thus the systems offering it were not surviving or: - the feature was considered important or nice to have, but decision which system to buy was not made based on important or desirable features.
I think it could be the latter. However, that means that introducing useful features will not sell your system... what a wonderful world.
I have always wondered why Microsoft, with the billions of dollars they scrape from customers, are not able to turn marketing speak into working software in shorter time. There should not be the problem of limited budgets, limited manpower etc. But still every time they announce new stuf in loud speak, then silently announce the postponement by one or several years.
The Unix filesystem has worked like that for decades... This is a major difference with Windows filesystems, where names are directly attached to files. In Windows, you cannot overwrite a file that is exclusively open by others (like an executable), so this must be handled at the application level. In Unix, you can create a new file at a new inode and have the original filename point to that instead of the original inode (which still has the old file but is no longer associated with a name).
>OR, how about full diskless clients, with BIOS manufactures being able to map specific locations on the network to a local harddrive via something like NBD(network block device) or some next-gen NFS. at 10Gb/s, your datatransfer is 1.164GBytes/s, minus overhead, lets say %25 to be safe, or just short of a GIGABYTE/s. how fast is your local hard drive? with a SAN, your could run a very fast RAID5 setup, with a rediculously large cache and have nearly instantanios access to 1,000s of large files. transfer a full DVD in 5-10 seconds, boot your machines faster because of increased datarates.
Todays disks run at about 60 MB/s. That is about 500 Mbit/s. Moving all your local disks to a central location will mean the LAN is again the bottleneck when you have over 20 workstations. And of course then there would have to be at least 20 disks in the server.
Considering the prices of workstation disks, the prices of server disks, the costs of LAN technology, and the limited advantages (remember you are just moving physical disks, not making things easier to manage or whatever), I don't think this is going to be a good idea.
Full diskless clients have been possible for a long time. But there are limitations, especially to the usefullness. And this remains the same.
SPF is going to provide you with that information. When a mail "from hotmail.com" is not coming from any of the declared hotmail servers, it is a spoof.
When you want to look at a real risk, consider the risk that BIG CORPORATION A, B, C, D and Microsoft get so fed-up with the spam and worm problems that they ask Microsoft to develop an entirely new, proprietary system for e-mail that replaces the current SMTP infrastructure. All users of Windows systems get the upgrade from WindowsUpdate, users of other systems will be forever locked out of e-mail (or moved onto the sidetrack of "legacy SMTP e-mail" that no user of the new system trusts).
I think *that* is a real risk, and to avoid it we should at least be less resistant to change in the existing system.
Yes, anyone who allows users to send spoofed mail (mail originating from elsewhere, but claiming to be from their domain) should setup authenticating SMTP servers accessible from the outside.
This is not so bad. It requires all the mail to go through their servers, where scanning for viruses can take place as well.
Well, in the company where I work the users have Windows 2000 systems on their desktop but none of them have more than "user" privilege on their system and they cannot write on the HD anywhere outside their user profile directory. This is just normal system administration policy and has nothing to do with the use of Linux.
The time it takes to go through the BIOS startup is not determined by the design of the BIOS as it is, but by the time it takes to do certain tests and the artifical delays added to display certain information to the user. Most BIOSes have option settings to select between fast and good tests, and to speedup the process. The Dell systems at work are well underway booting the OS before the CRT has even warmed up.
I think the boot time advantage is not worth the trouble.
An Xbox is a proprietary piece of technology that you buy with the knowledge that it is only designed to run games that are licensed for it. This is something that is allowed, especially as there are a couple of other, competing, game consoles from other manufacturers.
However, I doubt that Microsoft or a trusted computing alliance will get away with changing the PC BIOS overnight so that only Microsoft operating systems can boot on every generic PC. By now, Linux has got enough momentum and is too wellknown by authorities to let that happen. (certainly in de European Union)
I think it is OK that the ISPs don't want to filter the traffic, but at the very least they should make available a system to send short messages to customers selected only by the IP address, without having to go through a manually handled abuse@isp address.
Of course this system should be protected against use for spamming. Something like a webpage, preferably with a standard URL, with the usual countermeasures against automatic use.
Many systems are infected with spamsending trojans without the owner knowing it, and as a victim you cannot inform the owner without the cooperation of the ISP. But the ISP often does not co-operate, either becasuse the abuse department is understaffed or because it has unreasonable policies. ("you need to supply full headers of the virus mail", "we take action only if we receive several complaints", etc)
The advantage of shared libraries is that they save space, both on disk and in main memory. This may be less of an issue now than at the time they were invented, but it still helps.
Furthermore, with a shared library you can fix a bug in a function by replacing a library. In your scenario, all binaries that have linked the function will need to be replaced.
But this filtering is quite difficult to do, especially with static rules. For example, from our webproxy we allow connects to certain ports only. The proxy can connect to ports like 80 and 443 (and some high port ranges). This works well 99% of the time, but sometimes sites setup a second server on a port like 81 and it cannot be connected.
There could be some magic like "the proxy software is allowed to do it but another process on that machine isn't". That is like ZoneAlarm. However, I question the utility of this approach, because when a cracker is able to install a trojan process that does outgoing connects, who guarantees me that he will not be able to defeat this magic filter?
Of course a trojan that is capable of installing itself without the user's consent and distribute itself and spam from the system, will also be able to tell ZoneAlarm that it has permission to send the outgoing traffic.
These trojans already try to (and succeed in) disable virus scanners. When ZoneAlarm would be a mandatory item or standard part of Windows, it would be targeted the same way.
That is why the idea of installing this functionality in an external device (cablemodem) is so much better than using something like ZoneAlarm. At least on systems where the user has administrative permissions by default.
Re:How is it implemened?
on
IPv6 is Here
·
· Score: 1
Slashdot Mirror
You would still have two conversions, one from mains to 12v and another from 12v to what you need.
That would include 12v. The battery voltage is too uncertain to use as 12v supply for the computer.
So, while running on battery the efficiency would be better (only the second converter would be running), but when running on the mains it would be worse. It would be like an online UPS.
With an offline UPS (the one that switches over when the power fails), the efficiency would be better during powered mode.
The best probably is to standardize on 48v when you need UPS service. Have the mains converted to 48v at a central place in your house, include 48v batteries, and use 48v supplies in your equipment.
(a supply that has 48vdc input).
This equipment is available, but because of the limited volume and more professional use, it costs way more than a standard supply and normal UPS.
Unused cables cluttering up the case?
I always have a shortage of cables, need to use splitter cables to connect everything.
IMHO, the extra connectors at the PSU side are a waste of space, series resistance, and reliability.
I have seen this happen with other Windows updates (hotfixes) as well!
When you run VMware, it by default creates a drive for sharing information between sessions. I think it is called Z: by default. The root directory of this drive is not writable, it contains folders that are writable.
Many updates fail when this condition is present.
I think the updater does a check for writability only via the ACLs, and fails to notice a drive that is non-writable by design, but does not advertise this via the ACL.
(of course it recognizes CD-ROM drives as non-writable)
What I want to state is that the average price of the average computer has not dropped that much.
It has dropped a bit, but not that much as when you look at price-per-memory-byte etc.
Sure I have spent lots of money on parts that are cheap now, like $400 for a floppydrive or $1000 for a 5MB diskdrive.
Sure when you compare byte-for-byte, the price has dropped dramatically over 20 years.
But when you compare price of a typical user's system, is the difference really that much?
Today a typical office desktop machine would be around 1000 euro (or US$). That is also what I paid for my first computer in 1980. Of course it had 16K instead of 512M of RAM, a tape recorder instead of a 120GB harddisk drive, a 2 MHz Z-80 processor instead of a 3 GHz Pentium 4, but the users of that time bought it for the same purpose as the users of today.
So while you get a lot more for your money today, it is not like the price of a desktop system dropped from 'about the same as a car' to 'about the same as a candybar'.
My experience is that it does not matter to where you outsource it. Any job outsourced to another company can result in bad quality code.
Remember that every company will tell you how good the quality of their programmers is, how good their methodology is, etc. But in the end they just allocate a bunch of programmers to your job, and every time a new (= always more important) job comes in, the best people are moved to there and a new load of trainees continues on your work.
This can happen when you outsource to India, but it may just as well happen when you outsource to a reputable company in your own country.
Of course it is easy, especially in the intrusive way it is done in VMS. It simply gives out new file numbers every time and shows the users all the versions of the file that are there. A simple patch would make that available in Linux (could be a little trickier when links and symlinks are considered as well).
/etc) but with this extra script that I run nightly from cron I keep al changes that have occured during a day in an RCS archive for each file on the system for which an RCS archive exists in an RCS/ subdirectory below the file.
Already better is the way it is done in Novell Netware. The old versions are normally not visible, the space they occupy is automatically released when the disk runs out of capacity, etc. The user normally does not see the versioning going on, but can still access it when required.
However, a really useful feature (especially for textfiles) would be automatic versioning by something like RCS or CVS. Those systems do not store the full files for every change, but only the diffs. That allows to store many more versions without running out of space, and to do more intelligent things like "remove the changes that occurred between version 11 and 12 from my current version 20 file and make that version 21 (current)".
In fact I use a script on many systems that I administer, that uses RCS for such a versioning. I dislike the "checkout, modify, checkin" paradigm that underlies RCS (and that makes it unusable for versioning files that are in actual use, like configuration files in
Having this as a builtin in the system would be a bonus, but as often it can be sort of simulated with an addon script.
One could conclude that either:
- this feature was not considered important by users and thus the systems offering it were not surviving
or:
- the feature was considered important or nice to have, but decision which system to buy was not made based on important or desirable features.
I think it could be the latter. However, that means that introducing useful features will not sell your system... what a wonderful world.
I have always wondered why Microsoft, with the billions of dollars they scrape from customers, are not able to turn marketing speak into working software in shorter time.
There should not be the problem of limited budgets, limited manpower etc.
But still every time they announce new stuf in loud speak, then silently announce the postponement by one or several years.
The Unix filesystem has worked like that for decades...
This is a major difference with Windows filesystems, where names are directly attached to files. In Windows, you cannot overwrite a file that is exclusively open by others (like an executable), so this must be handled at the application level.
In Unix, you can create a new file at a new inode and have the original filename point to that instead of the original inode (which still has the old file but is no longer associated with a name).
That can hardly be called innovative. VMS and Novell, and probably others, had this 15 years ago.
>OR, how about full diskless clients, with BIOS manufactures being able to map specific locations on the network to a local harddrive via something like NBD(network block device) or some next-gen NFS. at 10Gb/s, your datatransfer is 1.164GBytes/s, minus overhead, lets say %25 to be safe, or just short of a GIGABYTE/s. how fast is your local hard drive? with a SAN, your could run a very fast RAID5 setup, with a rediculously large cache and have nearly instantanios access to 1,000s of large files. transfer a full DVD in 5-10 seconds, boot your machines faster because of increased datarates.
Todays disks run at about 60 MB/s. That is about 500 Mbit/s.
Moving all your local disks to a central location will mean the LAN is again the bottleneck when you have over 20 workstations. And of course then there would have to be at least 20 disks in the server.
Considering the prices of workstation disks, the prices of server disks, the costs of LAN technology, and the limited advantages (remember you are just moving physical disks, not making things easier to manage or whatever), I don't think this is going to be a good idea.
Full diskless clients have been possible for a long time. But there are limitations, especially to the usefullness. And this remains the same.
SPF is going to provide you with that information.
When a mail "from hotmail.com" is not coming from any of the declared hotmail servers, it is a spoof.
When you want to look at a real risk, consider the risk that BIG CORPORATION A, B, C, D and Microsoft get so fed-up with the spam and worm problems that they ask Microsoft to develop an entirely new, proprietary system for e-mail that replaces the current SMTP infrastructure.
All users of Windows systems get the upgrade from WindowsUpdate, users of other systems will be forever locked out of e-mail (or moved onto the sidetrack of "legacy SMTP e-mail" that no user of the new system trusts).
I think *that* is a real risk, and to avoid it we should at least be less resistant to change in the existing system.
Yes, anyone who allows users to send spoofed mail (mail originating from elsewhere, but claiming to be from their domain) should setup authenticating SMTP servers accessible from the outside.
This is not so bad. It requires all the mail to go through their servers, where scanning for viruses can take place as well.
Sure. As long as you use a mail address for which your ISP is listed as a valid sending server.
(that will probably be an address at your ISP)
No. Most of them do NOT support TXT records.
This will have to change, or SPF will be useless.
Well, in the company where I work the users have Windows 2000 systems on their desktop but none of them have more than "user" privilege on their system and they cannot write on the HD anywhere outside their user profile directory.
This is just normal system administration policy and has nothing to do with the use of Linux.
The time it takes to go through the BIOS startup is not determined by the design of the BIOS as it is, but by the time it takes to do certain tests and the artifical delays added to display certain information to the user.
Most BIOSes have option settings to select between fast and good tests, and to speedup the process.
The Dell systems at work are well underway booting the OS before the CRT has even warmed up.
I think the boot time advantage is not worth the trouble.
An Xbox is a proprietary piece of technology that you buy with the knowledge that it is only designed to run games that are licensed for it. This is something that is allowed, especially as there are a couple of other, competing, game consoles from other manufacturers.
However, I doubt that Microsoft or a trusted computing alliance will get away with changing the PC BIOS overnight so that only Microsoft operating systems can boot on every generic PC. By now, Linux has got enough momentum and is too wellknown by authorities to let that happen.
(certainly in de European Union)
I think it is OK that the ISPs don't want to filter the traffic, but at the very least they should make available a system to send short messages to customers selected only by the IP address, without having to go through a manually handled abuse@isp address.
Of course this system should be protected against use for spamming. Something like a webpage, preferably with a standard URL, with the usual countermeasures against automatic use.
Many systems are infected with spamsending trojans without the owner knowing it, and as a victim you cannot inform the owner without the cooperation of the ISP.
But the ISP often does not co-operate, either becasuse the abuse department is understaffed or because it has unreasonable policies.
("you need to supply full headers of the virus mail", "we take action only if we receive several complaints", etc)
The advantage of shared libraries is that they save space, both on disk and in main memory.
This may be less of an issue now than at the time they were invented, but it still helps.
Furthermore, with a shared library you can fix a bug in a function by replacing a library. In your scenario, all binaries that have linked the function will need to be replaced.
But this filtering is quite difficult to do, especially with static rules.
For example, from our webproxy we allow connects to certain ports only. The proxy can connect to ports like 80 and 443 (and some high port ranges).
This works well 99% of the time, but sometimes sites setup a second server on a port like 81 and it cannot be connected.
There could be some magic like "the proxy software is allowed to do it but another process on that machine isn't". That is like ZoneAlarm.
However, I question the utility of this approach, because when a cracker is able to install a trojan process that does outgoing connects, who guarantees me that he will not be able to defeat this magic filter?
Of course a trojan that is capable of installing itself without the user's consent and distribute itself and spam from the system, will also be able to tell ZoneAlarm that it has permission to send the outgoing traffic.
These trojans already try to (and succeed in) disable virus scanners. When ZoneAlarm would be a mandatory item or standard part of Windows, it would be targeted the same way.
That is why the idea of installing this functionality in an external device (cablemodem) is so much better than using something like ZoneAlarm. At least on systems where the user has administrative permissions by default.
Ok so what is the French word for 6 ?