Sorry, I disagree. Webcam drivers and the like DO NOT BELONG IN THE KERNEL. The V4L (or V4L2) ABI should be stable enough where vendors can provide userland drivers and the kernel people shouldn't be worrying about it AT ALL. Specific device drivers have no business being in kernel space. The various ABIs should be stable over the major version numbers: 2.4.x, 2.6.x, etc. The current way is dangerous, sloppy and one of the major reasons Linux has issues like this with off-the-shelf hardware.
I mean, they did that for printers, why not every other piece of hardware?
Cell towers are like big access points. There is a cable or fiber going back to the Central Office (CO) called a "backhaul". The CO has a bunch of ATM and ESS switches that switch calls from tower to tower (handoff) and route calls to other phones, including other networks.
The backhaul size going back to the CO is one factor in determining the number of simultaneous calls that tower can process. For example, older towers used to use T-1 circuits, which allow for approximately 24 simultaneous calls. They're 1.54 Mbps for data rate. Towers in high traffic areas will sometimes have DS-3 coax (~45 Mbps) or even (rarely) OC-3 optical connections (~155.52 Mbps). There is about 4% overhead taken on those numbers, so actual payload thruput is less.
Bars show you signal strength, but not how "busy" the tower is at that moment. That is why you can get "bars", but calls don't go thru. You can see the tower clearly, it is just super busy.
Considering you linked the Release Notes, *you* should know what "technology preview" means.
Technology Preview features are currently not supported under Red Hat Enterprise Linux subscription services, may not be functionally complete, and are generally not suitable for production use. However, these features are included as a customer convenience and to provide the feature with wider exposure.
glibc new MALLOC behaviour: The upstream glibc has been changed recently to enable higher scalability across many sockets and cores. This is done by assigning threads their own memory pools and by avoiding locking in some situations. The amount of additional memory used for the memory pools (if any) can be controlled using the environment variables MALLOC_ARENA_TEST and MALLOC_ARENA_MAX. MALLOC_ARENA_TEST specifies that a test for the number of cores is performed once the number of memory pools reaches this value. MALLOC_ARENA_MAX sets the maximum number of memory pools used, regardless of the number of cores.
The glibc in the RHEL 5.4 release has this functionality integrated as a Technology Preview of the upstream malloc. To enable the per-thread memory pools the environment variable MALLOC_PER_THREAD needs to be set in the environment. This environment variable will become obsolete when this new malloc behaviour becomes default in future releases. Users experiencing contention for the malloc resources could try enabling this option.
But software which OpenBSD uses and redistributes must be free to all (be they people or companies) for any purpose they wish to use it, including modification, use, peeing on, or even integration into baby mulching machines or atomic bombs to be dropped on Australia.
I always thought it was just clueless marketing morons who couldn't do math. The same group of people responsible for marketing CRT-based monitor sizes (the TUBE is 17", including behind the 2" bezel), tape drive storage capacities (assuming 2:1 compression ratio!) and all electronics battery life measurements (examples too numerous to list).
I can't count the number of times I had to explain to people who bought an extra hard drive where 3% of it disappeared when they checked the size in Windows Explorer.
While Apple is certainly rules by the marketing drones, they aren't morons by any stretch of the imagination. I think the engineering people finally just gave in when their grandmother called and asked why her new 500 GB drive was only showing 482 GB when installed. I can hear them crying with frustration all the way over on the other coast.
I wasn't bashing Slackware in general, just Patrick's irrational dislike of PAM.
PAM provides functionality that is very useful. For example, easy enforcement of password complexity policy or restricting authentication to valid X.509 certificates.
The idea of "if you break it, you can hose your system" goes 100% against what you just wrote. Breaking things is how you learn, and Slackware is about deep understanding of the system. Besides, PAM isn't that fragile. I've used it in setups consisting of thousands of networked systems in mission critical environments. It is quite robust.
I believe Patrick's main justification is that it adds a layer of potential risk and complexity, and that there was once a vulnerability in PAM that weakened or exposed login authentication.
My answer is damn near EVERYTHING provides an additional layer of potential risk and complexity, and if you discounted every component that had a vulnerability we'd be restricted to "Hello, world!"
Anyway, my original question was about PAM and HAL while the one reply rant was specifically addressing HAL. HAL has since been integrated into Slackware, so the point is moot. Slackware is a great learning distro and PAM is something that competent administrators should learn. Let those who aren't interested in learning the WHY, only what button to push, infest the Ubuntu forums.
My philosophy is do it the long, hard, manual way once so you learn it, then automate it with the computer. The same reason I'm using network manager instead of writing WPA-supplicant rules by hand; or using IKE instead of writing IPSec SPAs and SPIs by hand.
Been there, done that, got the t-shirt, now I want to be able to move on and do something else while having the computer handle the tedious details.
It is simpler than that. Maemo 5 uses gstreamer and there is an ogg-support package in the Extras repository. Add repository, install package, and the existing media player should now support vorbis. Ogg support was added fairly quickly for the older versions of the software. I wouldn't be surprised to see FLAC added fairly quickly as well.
From what I understand, Maemo 5 is a mix of GTK+ and Qt, as horrid as that sounds. It is a "transition" release, mostly more polished than previous versions but with the hooks necessary for multi-core, multi-processor, accelerated 3D graphics, accelerometers and Qt support.
If the N810 is your first, then you might be disappointed to not see a load for it. If you'd been around before, this would come as no shock. There was no official support for the N770 beyond the initial release, except in a community-supported "hacker edition". Mer came along nicely.
[searching...]
It seems the alpha of the Freemantle SDK worked on the N810 but the beta and later did not. Speculation is because of the closed-source 3D accelerated graphics drivers that were introduced in the beta. You might see a "hacker edition" but without all the extra hardware (new CPU, accelerometers, 3d graphics, etc.) it'll probably just disappoint.
I had the N770, but skipped the N800 and N810 for the reason you mentioned -- poor video support. The reason was a hardware design that limited the pipeline between the graphics co-processor and the CPU. It was technically impossible to get decent accelerated video on the N770 and N8x0 models. They were hardware crippled. (Search the Internet Tablet Talk forums for discussions on this.)
The N900 doesn't have that issue. It was fixed essentially with the upgrade to the Cortex CPU and a better design.
The iPhone can play video just fine. It is, however, Quicktime video, where Apple has everything it needs to do it right. The whole "lack of Flash" strikes me as a licensing issue, or maybe a lack of hardware acceleration support on ARM by Adobe. If they don't the Cortex-A8 may have enough oomph to get proper Flash video rates.
Here's hoping HTML-5 catches on an Flash dies a horrible, agonizing death.
Maemo 5 includes the Telepathy framework, which seems to either be working on or has SIP integration.
The phone includes Skype that works over WiFi or 3G, so there is no inherent restriction on VoIP. I'd expect to see Google Voice for it fairly quickly as well.
This is a NOKIA phone. Nokia is one of the two main companies that objected to OGG formats (vorbis & theora) being specified in the HTML5 spec. They aren't fully confident about the patent situation regarding OGG.
By "liquid petroleum gas" they probably mean LP, or liquid propane though it could also be liquid butane or a mix of the two. It is significantly cleaner burning than gasoline. Consider that it is used to heat the water and not drive the pistons, you are using significantly less petroleum to move the same size vehicle.
Also, steam is much more efficient in powering a piston than gasoline explosions. Steam expands continuously through the piston stroke, as opposed to just a "bang" and push from the combusting of gasoline or diesel. Exhaust is a lot cleaner as well.
One downside is that, in a fire, you have a BLEVE potential.
While I'm uncertain if this car uses a turbine or traditional steam piston drive, steam turbines are responsible for about 80% of the electricity generated in the world. It is very efficient. Remember, a nuclear plant is just an efficient steam generator which is in turn used to drive a turbine.
Thermal conductivity, which is his main reason for installing this system. PEX tubing does not transfer heat as readily as copper, and so conserves energy. Not the ideal solution for someone WANTING to transfer heat.
He lives in northern Tasmania, not Hawaii. I believe freezing -- or hard freezes -- are fairly rare there. Even then, copper embedded in concrete has been used for many decades and it isn't as big an issue as you seem to think. http://www.copper.org/applications/plumbing/benefits/benefits_main.html
Slashdot Mirror
Sorry, I disagree. Webcam drivers and the like DO NOT BELONG IN THE KERNEL. The V4L (or V4L2) ABI should be stable enough where vendors can provide userland drivers and the kernel people shouldn't be worrying about it AT ALL. Specific device drivers have no business being in kernel space. The various ABIs should be stable over the major version numbers: 2.4.x, 2.6.x, etc. The current way is dangerous, sloppy and one of the major reasons Linux has issues like this with off-the-shelf hardware.
I mean, they did that for printers, why not every other piece of hardware?
Cell towers are like big access points. There is a cable or fiber going back to the Central Office (CO) called a "backhaul". The CO has a bunch of ATM and ESS switches that switch calls from tower to tower (handoff) and route calls to other phones, including other networks.
The backhaul size going back to the CO is one factor in determining the number of simultaneous calls that tower can process. For example, older towers used to use T-1 circuits, which allow for approximately 24 simultaneous calls. They're 1.54 Mbps for data rate. Towers in high traffic areas will sometimes have DS-3 coax (~45 Mbps) or even (rarely) OC-3 optical connections (~155.52 Mbps). There is about 4% overhead taken on those numbers, so actual payload thruput is less.
Bars show you signal strength, but not how "busy" the tower is at that moment. That is why you can get "bars", but calls don't go thru. You can see the tower clearly, it is just super busy.
Your entire post rests entirely on unfalsifiable statements, conjecture and unsubstantiated claims about evidence.
Dude, this is Slashdot. What exactly did you expect?
No, it was actually about 8 1/2 years later, if you don't count the birthday announcements, etc. May 1, 1978 to be exact.
http://www.templetons.com/brad/spamreact.html
Considering you linked the Release Notes, *you* should know what "technology preview" means.
Technology Preview features are currently not supported under Red Hat Enterprise Linux subscription services, may not be functionally complete, and are generally not suitable for production use. However, these features are included as a customer convenience and to provide the feature with wider exposure.
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Release_Notes/sect-Release_Notes-Technology_Previews.html
glibc new MALLOC behaviour: The upstream glibc has been changed recently to enable higher scalability across many sockets and cores. This is done by assigning threads their own memory pools and by avoiding locking in some situations. The amount of additional memory used for the memory pools (if any) can be controlled using the environment variables MALLOC_ARENA_TEST and MALLOC_ARENA_MAX.
MALLOC_ARENA_TEST specifies that a test for the number of cores is performed once the number of memory pools reaches this value. MALLOC_ARENA_MAX sets the maximum number of memory pools used, regardless of the number of cores.
The glibc in the RHEL 5.4 release has this functionality integrated as a Technology Preview of the upstream malloc. To enable the per-thread memory pools the environment variable MALLOC_PER_THREAD needs to be set in the environment. This environment variable will become obsolete when this new malloc behaviour becomes default in future releases. Users experiencing contention for the malloc resources could try enabling this option.
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Release_Notes/
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Technical_Notes/
You know...this could help explain the obesity levels of American's. It is Pac Man's fault! Quick! Where's my lawyer!
Woosh!
This is a dupe, though I'm too lazy to look it up. It is about a week old or so.
It was reported by a hacker on his blog. He worked for the gov't of Switzerland and it was done on their dime.
Screenshots? How about a torrent!
But software which OpenBSD uses and redistributes must be free to all (be they people or companies) for any purpose they wish to use it, including modification, use, peeing on, or even integration into baby mulching machines or atomic bombs to be dropped on Australia.
--Theo de Raadt
http://www.monkey.org/openbsd/archive/source-changes/0105/msg01243.html
Free means free, not "free only if I approve of what you do/look like/think/etc.
So...the reference is the Spanish Inquisition?
I always thought it was just clueless marketing morons who couldn't do math. The same group of people responsible for marketing CRT-based monitor sizes (the TUBE is 17", including behind the 2" bezel), tape drive storage capacities (assuming 2:1 compression ratio!) and all electronics battery life measurements (examples too numerous to list).
I can't count the number of times I had to explain to people who bought an extra hard drive where 3% of it disappeared when they checked the size in Windows Explorer.
While Apple is certainly rules by the marketing drones, they aren't morons by any stretch of the imagination. I think the engineering people finally just gave in when their grandmother called and asked why her new 500 GB drive was only showing 482 GB when installed. I can hear them crying with frustration all the way over on the other coast.
Yes, but...
I wasn't bashing Slackware in general, just Patrick's irrational dislike of PAM.
PAM provides functionality that is very useful. For example, easy enforcement of password complexity policy or restricting authentication to valid X.509 certificates.
The idea of "if you break it, you can hose your system" goes 100% against what you just wrote. Breaking things is how you learn, and Slackware is about deep understanding of the system. Besides, PAM isn't that fragile. I've used it in setups consisting of thousands of networked systems in mission critical environments. It is quite robust.
I believe Patrick's main justification is that it adds a layer of potential risk and complexity, and that there was once a vulnerability in PAM that weakened or exposed login authentication.
My answer is damn near EVERYTHING provides an additional layer of potential risk and complexity, and if you discounted every component that had a vulnerability we'd be restricted to "Hello, world!"
Anyway, my original question was about PAM and HAL while the one reply rant was specifically addressing HAL. HAL has since been integrated into Slackware, so the point is moot. Slackware is a great learning distro and PAM is something that competent administrators should learn. Let those who aren't interested in learning the WHY, only what button to push, infest the Ubuntu forums.
Sorry, no.
My philosophy is do it the long, hard, manual way once so you learn it, then automate it with the computer. The same reason I'm using network manager instead of writing WPA-supplicant rules by hand; or using IKE instead of writing IPSec SPAs and SPIs by hand.
Been there, done that, got the t-shirt, now I want to be able to move on and do something else while having the computer handle the tedious details.
Nice rant, though.
Did Patrick ever get over his irrational hatred of PAM and HAL? Or are these still left as an exercise for the student?
Correction:
Additional features
* 3D Accelerometer
* Ambient Light Sensor
* Nokia Maps
* Ovi Files
* Ovi Share
* Proximity Sensor
http://talk.maemo.org/showthread.php?t=31005
It is simpler than that. Maemo 5 uses gstreamer and there is an ogg-support package in the Extras repository. Add repository, install package, and the existing media player should now support vorbis. Ogg support was added fairly quickly for the older versions of the software. I wouldn't be surprised to see FLAC added fairly quickly as well.
From what I understand, Maemo 5 is a mix of GTK+ and Qt, as horrid as that sounds. It is a "transition" release, mostly more polished than previous versions but with the hooks necessary for multi-core, multi-processor, accelerated 3D graphics, accelerometers and Qt support.
If the N810 is your first, then you might be disappointed to not see a load for it. If you'd been around before, this would come as no shock. There was no official support for the N770 beyond the initial release, except in a community-supported "hacker edition". Mer came along nicely.
[searching...]
It seems the alpha of the Freemantle SDK worked on the N810 but the beta and later did not. Speculation is because of the closed-source 3D accelerated graphics drivers that were introduced in the beta. You might see a "hacker edition" but without all the extra hardware (new CPU, accelerometers, 3d graphics, etc.) it'll probably just disappoint.
Oh, and Qt is v4.5. http://blogs.forum.nokia.com/blog/kate-alholas-forum-nokia-blog/2009/03/02/qt4.5-for-maemo-5-fremantle-sdk
Mmmm...not quite.
I had the N770, but skipped the N800 and N810 for the reason you mentioned -- poor video support. The reason was a hardware design that limited the pipeline between the graphics co-processor and the CPU. It was technically impossible to get decent accelerated video on the N770 and N8x0 models. They were hardware crippled. (Search the Internet Tablet Talk forums for discussions on this.)
The N900 doesn't have that issue. It was fixed essentially with the upgrade to the Cortex CPU and a better design.
The iPhone can play video just fine. It is, however, Quicktime video, where Apple has everything it needs to do it right. The whole "lack of Flash" strikes me as a licensing issue, or maybe a lack of hardware acceleration support on ARM by Adobe. If they don't the Cortex-A8 may have enough oomph to get proper Flash video rates.
Here's hoping HTML-5 catches on an Flash dies a horrible, agonizing death.
Maemo 5 includes the Telepathy framework, which seems to either be working on or has SIP integration.
The phone includes Skype that works over WiFi or 3G, so there is no inherent restriction on VoIP. I'd expect to see Google Voice for it fairly quickly as well.
Surprised? You need to keep up on your geek news.
This is a NOKIA phone. Nokia is one of the two main companies that objected to OGG formats (vorbis & theora) being specified in the HTML5 spec. They aren't fully confident about the patent situation regarding OGG.
Maemo 5 aka Freemantle: http://flors.wordpress.com/2009/08/27/software-freedom-lovers-here-comes-maemo-5/
Official Nokia Site: http://maemo.nokia.com/
Developer's Guide: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide
Forums: http://talk.maemo.org/forumdisplay.php?f=40
By "liquid petroleum gas" they probably mean LP, or liquid propane though it could also be liquid butane or a mix of the two. It is significantly cleaner burning than gasoline. Consider that it is used to heat the water and not drive the pistons, you are using significantly less petroleum to move the same size vehicle.
Also, steam is much more efficient in powering a piston than gasoline explosions. Steam expands continuously through the piston stroke, as opposed to just a "bang" and push from the combusting of gasoline or diesel. Exhaust is a lot cleaner as well.
One downside is that, in a fire, you have a BLEVE potential.
While I'm uncertain if this car uses a turbine or traditional steam piston drive, steam turbines are responsible for about 80% of the electricity generated in the world. It is very efficient. Remember, a nuclear plant is just an efficient steam generator which is in turn used to drive a turbine.
Thermal conductivity, which is his main reason for installing this system. PEX tubing does not transfer heat as readily as copper, and so conserves energy. Not the ideal solution for someone WANTING to transfer heat.
He lives in northern Tasmania, not Hawaii. I believe freezing -- or hard freezes -- are fairly rare there. Even then, copper embedded in concrete has been used for many decades and it isn't as big an issue as you seem to think. http://www.copper.org/applications/plumbing/benefits/benefits_main.html