I still remember arguing with a stubborn idiot who kept insisting operating systems are not computer applications. Guess he was one of those students, "pushing literacy in bold new directions".
It is called anti-features. The "Windows 7 Sins" website mentioned it. I love that term. When it costs more for a vendor to remove a feature they sort of got for free - natural effect of smart design - yet they remove it anyway for political, administrative, and marketing reasons - it is an anti-feature. Manually and permanently reducing amount of concurrent TCP/IP connections available in Windows NT Workstation versus Windows NT Server (which does not cap the limit) despite both versions sharing the same code - antifeature. Limiting amount of applications that can be open simultaneously on one Windows version versus not doing so in another, when both share the same code again - antifeature. Filtering game client list based on platform, despite protocol potentially capable of providing inter-platform gameplay - antifeature. Everything that is destined for the consumer goes through marketing before it leaves the vendor. It is the fear of not making enough money.
Hilarious read. Especially the last one, where the seasoned coder invites the younger one to his office and shows him the code line where he pre-allocated 2Mb of memory, so that he can remove it when the project is due shipping after memory constraints are check. I would say this kind of practice will do good on any project from text editors to NASA computer controllers. People respond very well to harsh reality, even if this reality is a bit "fake". Cut down on perceived memory and slow down (intentionally) the CPU, and give them a go at programming. After they are done with polishing code enough so that it runs at decent performance, remove the constraints and see it fly! This is especially good practice for Microsoft, with their ever increasing system requirements and not increasing functionality.
The thing with these "switchable graphics" setups is that unfortunately with Linux, X Server does not yet know how to handle the runtime switching of the chipset. Every manufacturer has their own BIOS that controls this, and so far, Linux folks have not been able to deduce the interface enough to start implementing. Switchable graphics is a driver-supported feature available only to Windows users at this time. With Linux, if you enable switchable graphics in BIOS, at best you will get both chipsets drawing power while using either. The only thing that works the same way as you would expect from a single chipset - only it drawing power - is to set it as the used chipset in BIOS. No runtime switching would be possible though. Search on "switchable graphics linux" or something for more information.
You basically need to become proficient in all those startup scripts. They are doing all the job, really. Okay, most of it. I did it on my laptop, Thinkpad T43. Let me see... Here it is: I edited the/etc/rc.local file which as far as I remember is executed every time the runlevel changes. More on it all - Google.
Depends on the notebook. Some disable charging and discharging battery when above a percentage and connected to the wall socket. Heat has to be substantial for the battery life to be "dramatically shortened". Sitting here with a Thinkpad T43 that is permanently connected to the wall and also permanently attached 7 cell battery, and it has had it for five years. Battery still records 50% total watt-hours output.
Newer Lenovo laptops sold by default with 60W adapters even refuse (BIOS lock) to throttle the Core 2 Duo CPU all the way up with battery removed and AC connected, because the adapter cannot guarantee enough power for the machine at all times, so BIOS "hardlocks" the frequency, so that the CPU does not use too much power and thus contribute to overdrawing the adapter output. The downside to this is that after much talk users were told to keep their battery inside the machine, which was the only way to allow the CPU to throttle up, because BIOS removed the lock, and so if the adapter was at a time overdrawn, the battery kicked in, and the laptop continued operating until adapter alone was sufficient (power draw 60W). The ironic in it also was that BIOS only changed the lock on startup, so removing battery in the middle of your user session while connected to AC would not lock the CPU from throttling up when necessary, but I have no idea what would happens if the adapter is not able to provide enough power at a certain point in time.
Syslog allows write caching using the "-". So, technically, you don't need to disable syslogd. You just need to edit syslog.conf and put dashes couple-three places. Fiddling yes, but may be better than disabling it altogether.
Don't get me started on Firefox. It uses high resolution timers for all sorts of things, when it should be sleeping instead. Your equivalent of an ADHD youth on speed, really.
Start Firefox, navigate to Slashdot (I have both AdBlock Plus and NoScript) and run "sudo powertop". See what is listed on top:-)
You are mixing terms all over. BIOS is software too, just very pervasive and persistent software. But it is the same kind of code that what you refer to as "software power management" is. Also, BIOS usually only does rudimentary power management, and since two conflicting procedures "power managing" the same hardware through the same port would be a bad idea, one of these is usually disabled - usually BIOS, it being simpler, so that the other one - the more advanced (hopefully, see OP:-) OS power management - can assume the "managing" role. Simplified explanation, but that is how it works. The advantage is again - refined control, including user control. BIOS is not only a black box, it also is a very stoneage UI - Once you set up PM in BIOS, it takes a restart and re-fiddling with its settings to change the PM again. ACPI is what should be used as a PM interface, but in reality it is usually a mix of ACPI and BIOS routines. This is where my knowledge stops unfortunately.
Second that nearly exact same kind of experince on a 12" (titanium) Powerbook G4 I had Ubuntu 7.04 (or so) on once. I had truly lousy time with it. Seems there is more to good user experience than closed hardware and thousands of man hours of reverse-engineering. Who would have thought:-)
Well, much of the commodity hardware that Linux runs on is still a black box for folks who develop Linux. Especially BIOSes.Those should be the very definition of "black box" term. Microsoft has the advantage of "communicating with the major hardware vendors" and stuff like that. Everyone else is basically ignored. Closed hardware is in a sense a problem much like closed source software is.
Except that touchpad events are flooding message queues at about 300Hz, while keyboard events do so at 5Hz for an average user, all the way up to "only" 80 for a good typist when typing a document.
Windows has OEM drivers which are [by design] tailored for hardware. Thinkpads, for example, install their own power management service and driver. Evidently, these help battery life. Newer ATI graphic card drivers install with "PowerPlay" thing which idles GPU when not used. Without such drivers OS has no idea how to manage hardware except standard I/O and VESA for graphics output, neither of which are very PM-aware.
They did not make their own products look any worse than disclosing battery life for Windows and Linux side by side. Same machine, two numbers. All it did is make "battery aware customers" want XP, which, given Microsoft history of lobbying and what not, probably is their doing as well.
Have you tried to spend even more time (assuming you did spend some) on www.lesswatts.org? All the tricks are there, even checking for tickless kernel, timer interrupts. Intels 'powertop' utility is my best friend with Linux power management.
Wikipedia has pretty good article(s) on everything PI - how to calculate it in different ways, history, and all those quirks you don't even imagine to think about, before you read about them:-)
"series of bits" of course is always a storage method, but I meant series of bits which just describe the parts to the left and right of decimal point, i.e. series of bits of a decimal number. Any value obviously is represented as "series of bits" in a modern binary computer, so I chose my words poorly there.
Also, when I meant "not computable", I meant the physical hardware support. Obviously, and I am sure it has already been done more than enough times, libraries exist that deal with rational numbers in a precise manner - i.e. 1/9 * 2 will yield 2 / 9 represented as exactly that - 2 / 9, no corners cut. A modern binary computer however, will yield 0.2222222222, repeat ad infinitum, which is an approximation.
Since we are talking about "computing" numbers anyway, it is worth noting that modern computers can only do binary math. Unless a number is represented as a series of bits, and we only currently have two prevailing storage standards - the floating point and the integer - a number such as 1/9 is, paradoxically, not definitely (i.e. precisely) computable by a computer:-) Of course one can write a software library that will deal with values represented as rational numbers, i.e. 1/9 with both 1 and 9 stored "as is" and the division defined in between. But my short (and probably not very important) point is that todays computers cannot deal with such numbers. For the most part of course.
I think you need to chill with us then, because 1) This article is not about the debut of the OS, it is about the "Behind Minuet" interview, which is not exactly the same thing; and 2) Slashdot covered the real debut much earlier than even 2005 (check the date on the article) - http://developers.slashdot.org/story/01/09/05/2248252/MenuetOS-Debuts
Funny how you mentioned "something that big". I think part of the point is when you write something in assembly, paradoxically, to a human, it seems smaller.
Actually his point stressed inferiority of "hand optimization" REGARDLESS of that factor of human time. He was talking specifically about the better ability of a sufficiently intelligent modern compiler to produce optimal code versus human attempting to to that, time spent regardless.
If we take into account the human time and the costs involved, then this is another discussion again, with different arguments.
I think Menuet devs know very well, that for anything but the x86, they are, as they say, "shit out of luck." It is fairly obvious to anybody here that Menuet OS is a fairly exotic pet project. That is all it ever is going to be, until the day x86 virtualization will be cheaper than no virtualization, which I personally hope never happens, and neither I think it ever will either. Thus I am not betting on Menuet OS being anything more than that - a pet project. It probably is very important in many ways, not in the least for the devs themselves, it being their child with a lot of good times they had with it - but let us be realistic - it is not a "modern", "mainstream" OS. Linux came out from the same exact mentality - Mr. Torvalds playing with his 386 - but that bathwater was abandoned out shortly thereafter, and the "baby" has grown really fast ever since. Where will Menuet OS grow? It has "written in assembly" as its very DEFINITION. If it is no longer written in assembly, which is the only way to abstract into something that CAN grow, it is no longer Menuet OS, is it?
Slashdot Mirror
I still remember arguing with a stubborn idiot who kept insisting operating systems are not computer applications. Guess he was one of those students, "pushing literacy in bold new directions".
It is called anti-features. The "Windows 7 Sins" website mentioned it. I love that term. When it costs more for a vendor to remove a feature they sort of got for free - natural effect of smart design - yet they remove it anyway for political, administrative, and marketing reasons - it is an anti-feature. Manually and permanently reducing amount of concurrent TCP/IP connections available in Windows NT Workstation versus Windows NT Server (which does not cap the limit) despite both versions sharing the same code - antifeature. Limiting amount of applications that can be open simultaneously on one Windows version versus not doing so in another, when both share the same code again - antifeature. Filtering game client list based on platform, despite protocol potentially capable of providing inter-platform gameplay - antifeature. Everything that is destined for the consumer goes through marketing before it leaves the vendor. It is the fear of not making enough money.
Hilarious read. Especially the last one, where the seasoned coder invites the younger one to his office and shows him the code line where he pre-allocated 2Mb of memory, so that he can remove it when the project is due shipping after memory constraints are check. I would say this kind of practice will do good on any project from text editors to NASA computer controllers. People respond very well to harsh reality, even if this reality is a bit "fake". Cut down on perceived memory and slow down (intentionally) the CPU, and give them a go at programming. After they are done with polishing code enough so that it runs at decent performance, remove the constraints and see it fly! This is especially good practice for Microsoft, with their ever increasing system requirements and not increasing functionality.
The thing with these "switchable graphics" setups is that unfortunately with Linux, X Server does not yet know how to handle the runtime switching of the chipset. Every manufacturer has their own BIOS that controls this, and so far, Linux folks have not been able to deduce the interface enough to start implementing. Switchable graphics is a driver-supported feature available only to Windows users at this time. With Linux, if you enable switchable graphics in BIOS, at best you will get both chipsets drawing power while using either. The only thing that works the same way as you would expect from a single chipset - only it drawing power - is to set it as the used chipset in BIOS. No runtime switching would be possible though. Search on "switchable graphics linux" or something for more information.
You basically need to become proficient in all those startup scripts. They are doing all the job, really. Okay, most of it. I did it on my laptop, Thinkpad T43. Let me see... Here it is: I edited the /etc/rc.local file which as far as I remember is executed every time the runlevel changes. More on it all - Google.
Depends on the notebook. Some disable charging and discharging battery when above a percentage and connected to the wall socket. Heat has to be substantial for the battery life to be "dramatically shortened". Sitting here with a Thinkpad T43 that is permanently connected to the wall and also permanently attached 7 cell battery, and it has had it for five years. Battery still records 50% total watt-hours output.
Newer Lenovo laptops sold by default with 60W adapters even refuse (BIOS lock) to throttle the Core 2 Duo CPU all the way up with battery removed and AC connected, because the adapter cannot guarantee enough power for the machine at all times, so BIOS "hardlocks" the frequency, so that the CPU does not use too much power and thus contribute to overdrawing the adapter output. The downside to this is that after much talk users were told to keep their battery inside the machine, which was the only way to allow the CPU to throttle up, because BIOS removed the lock, and so if the adapter was at a time overdrawn, the battery kicked in, and the laptop continued operating until adapter alone was sufficient (power draw 60W). The ironic in it also was that BIOS only changed the lock on startup, so removing battery in the middle of your user session while connected to AC would not lock the CPU from throttling up when necessary, but I have no idea what would happens if the adapter is not able to provide enough power at a certain point in time.
Syslog allows write caching using the "-". So, technically, you don't need to disable syslogd. You just need to edit syslog.conf and put dashes couple-three places. Fiddling yes, but may be better than disabling it altogether.
Don't get me started on Firefox. It uses high resolution timers for all sorts of things, when it should be sleeping instead. Your equivalent of an ADHD youth on speed, really.
Start Firefox, navigate to Slashdot (I have both AdBlock Plus and NoScript) and run "sudo powertop". See what is listed on top :-)
You are mixing terms all over. BIOS is software too, just very pervasive and persistent software. But it is the same kind of code that what you refer to as "software power management" is. Also, BIOS usually only does rudimentary power management, and since two conflicting procedures "power managing" the same hardware through the same port would be a bad idea, one of these is usually disabled - usually BIOS, it being simpler, so that the other one - the more advanced (hopefully, see OP :-) OS power management - can assume the "managing" role. Simplified explanation, but that is how it works. The advantage is again - refined control, including user control. BIOS is not only a black box, it also is a very stoneage UI - Once you set up PM in BIOS, it takes a restart and re-fiddling with its settings to change the PM again. ACPI is what should be used as a PM interface, but in reality it is usually a mix of ACPI and BIOS routines. This is where my knowledge stops unfortunately.
Second that nearly exact same kind of experince on a 12" (titanium) Powerbook G4 I had Ubuntu 7.04 (or so) on once. I had truly lousy time with it. Seems there is more to good user experience than closed hardware and thousands of man hours of reverse-engineering. Who would have thought :-)
Well, much of the commodity hardware that Linux runs on is still a black box for folks who develop Linux. Especially BIOSes.Those should be the very definition of "black box" term. Microsoft has the advantage of "communicating with the major hardware vendors" and stuff like that. Everyone else is basically ignored. Closed hardware is in a sense a problem much like closed source software is.
Except that touchpad events are flooding message queues at about 300Hz, while keyboard events do so at 5Hz for an average user, all the way up to "only" 80 for a good typist when typing a document.
Interesting indeed.
Windows has OEM drivers which are [by design] tailored for hardware. Thinkpads, for example, install their own power management service and driver. Evidently, these help battery life. Newer ATI graphic card drivers install with "PowerPlay" thing which idles GPU when not used. Without such drivers OS has no idea how to manage hardware except standard I/O and VESA for graphics output, neither of which are very PM-aware.
They did not make their own products look any worse than disclosing battery life for Windows and Linux side by side. Same machine, two numbers. All it did is make "battery aware customers" want XP, which, given Microsoft history of lobbying and what not, probably is their doing as well.
Have you tried to spend even more time (assuming you did spend some) on www.lesswatts.org?
All the tricks are there, even checking for tickless kernel, timer interrupts. Intels 'powertop' utility is my best friend with Linux power management.
Wikipedia has pretty good article(s) on everything PI - how to calculate it in different ways, history, and all those quirks you don't even imagine to think about, before you read about them :-)
Errata:
"series of bits" of course is always a storage method, but I meant series of bits which just describe the parts to the left and right of decimal point, i.e. series of bits of a decimal number. Any value obviously is represented as "series of bits" in a modern binary computer, so I chose my words poorly there.
Also, when I meant "not computable", I meant the physical hardware support. Obviously, and I am sure it has already been done more than enough times, libraries exist that deal with rational numbers in a precise manner - i.e. 1/9 * 2 will yield 2 / 9 represented as exactly that - 2 / 9, no corners cut. A modern binary computer however, will yield 0.2222222222, repeat ad infinitum, which is an approximation.
Since we are talking about "computing" numbers anyway, it is worth noting that modern computers can only do binary math. Unless a number is represented as a series of bits, and we only currently have two prevailing storage standards - the floating point and the integer - a number such as 1/9 is, paradoxically, not definitely (i.e. precisely) computable by a computer :-) Of course one can write a software library that will deal with values represented as rational numbers, i.e. 1/9 with both 1 and 9 stored "as is" and the division defined in between. But my short (and probably not very important) point is that todays computers cannot deal with such numbers. For the most part of course.
Just because nobody has detected a pattern doesn't mean there is one.
I think you need to chill with us then, because 1) This article is not about the debut of the OS, it is about the "Behind Minuet" interview, which is not exactly the same thing; and 2) Slashdot covered the real debut much earlier than even 2005 (check the date on the article) - http://developers.slashdot.org/story/01/09/05/2248252/MenuetOS-Debuts
That's like having the best of two worlds: human readable code that maps directly to the problem at hand AND very well optimized generated code
That's the Holy Grail of computer programming science. That and the right diet for software developers :-)
Funny how you mentioned "something that big". I think part of the point is when you write something in assembly, paradoxically, to a human, it seems smaller.
Actually his point stressed inferiority of "hand optimization" REGARDLESS of that factor of human time. He was talking specifically about the better ability of a sufficiently intelligent modern compiler to produce optimal code versus human attempting to to that, time spent regardless.
If we take into account the human time and the costs involved, then this is another discussion again, with different arguments.
I think Menuet devs know very well, that for anything but the x86, they are, as they say, "shit out of luck." It is fairly obvious to anybody here that Menuet OS is a fairly exotic pet project. That is all it ever is going to be, until the day x86 virtualization will be cheaper than no virtualization, which I personally hope never happens, and neither I think it ever will either. Thus I am not betting on Menuet OS being anything more than that - a pet project. It probably is very important in many ways, not in the least for the devs themselves, it being their child with a lot of good times they had with it - but let us be realistic - it is not a "modern", "mainstream" OS. Linux came out from the same exact mentality - Mr. Torvalds playing with his 386 - but that bathwater was abandoned out shortly thereafter, and the "baby" has grown really fast ever since. Where will Menuet OS grow? It has "written in assembly" as its very DEFINITION. If it is no longer written in assembly, which is the only way to abstract into something that CAN grow, it is no longer Menuet OS, is it?