It seems you're not familiar with the process of software development. You just don't issue one single commit containing a billion changes. It's a step by step process, for several reasons, most importantly the mechanic and iterative process of searching for bugs.
Still runs just as good as the day I bought it 10 years ago, incl. the HDD that came with it. The CCFL backlight in the screen has lost a lot of brightness output, though.
All of my old home computers I kept are still in 100% working conditions - a few C64s, Amigas, Ataris etc. In terms of more modern computing, my best example would be my home server/router which is a 14-15 years old Abit BF6 motherboard with a low-power passively cooled P3-600/133 and 512MB of RAM. This machine and its original 200W PSU saw 8-10 hours of use 5 days a week during 2000-2004, and from 2004 to this very day - 10 years - it has been running 24/7 as my home server/router, without failure. The only thing that has been replaced in that machine is the original HDD I bought with it, a 12GB Fujitsu drive, that died in 2010, after 10 years of service. They don't make 'em like they used to.
Small explanation: what happens is that when the SSHd matches the user's login group successfully, it forcefully switches over to the internal sftp component instead of the default external subsystem, which in turn makes it possible to chroot the user to his/her home dir without having to place a plethora of system files in each user's home directory.
Proper support for power-saving clients comes down to buffering outgoing packets until the client asks the AP for them, rather then instantly sending them to the client which may or may not be asleep at that point. This is not a driver firmware issue, it's a fundamental stack problem and lies entirely in the hands of the OpenBSD developers.
There is no need for third-party tools for what you want to achieve. While the solution is a bit ungainly, all of it is already supported by OpenSSH and its sftp subsystem. This is how I configured things on my system:
First off, add a group that you call f.e. "sftponly". New users that are to be allowed only sftp access should have "sftponly" as their login group, and have/sbin/nologin as shell to deny them shell access. Their home directories should be owned by root:sftponly, and within the home dir you then create relevant user-controllable directories which should be owned by:sftponly.
Secondly, the sshd_config magic that makes the whole charade work:
Subsystem sftp/usr/libexec/sftp-server
Match Group sftponly
ForceCommand internal-sftp
ChrootDirectory %h
I've been using OpenBSD as my wireless home router, server and development platform since 2005, and can from 9 years of experience safely say that the current state of OpenBSD's Wi-Fi drivers and 802.11 stack is troubling. On one hand, most chipsets out there have rudimentary driver support in OpenBSD, including WPA2 and CCMP facilities. On the other hand, the 802.11 stack still lacks 11n support (minor problem) but what's much worse is that while only two of the drivers - ral(4) and athn(4) - state that they can handle power-saving clients when running in HostAP mode, none of them actually do it properly. None of the support ral(4) chipsets can handle power-saving clients despite what the ral(4) man page claims, and while athn(4) works slightly better it's still flaky with unreliable results, no matter what wireless chipset the client uses. The effect is that OpenBSD is useless as a wireless access point without having the clients pull one of several tricks available to avoid them from entering power-saving mode, as have been posted and explained by troubled users on the OBSD mailing lists regularly over the years.
I understand that Wi-Fi portions of OpenBSD aren't exactly prioritized, but are these issues even on the roadmap?
It's about the cost, not the coffee or the effort. High price tags attract people who suffer the "spender syndrome" - dishing out a lot of money on something even plain or generic gives these people a feeling of being above the average, being set aside from the rest of us, of enjoying something that is "exclusive" only to their kind.
It's like when you find the exact same piece of generic furniture sold at (but not designed by) IKEA in some upstreet furniture shop - IKEA would call it "ROBUST" (or whatever) and sell it for $89, while the other "boutique" will call it "Multimedia bench in Nordic pinewood" at thrice the pricetag. People with money will buy it, and they will feel like they did a better deal than paying $89 at IKEA. It's one of the oldest tricks in the book of retail.
You're suffering a fundamental misunderstanding of the Bitcoin protocol. The entire currency as it stands at any point in time is contained within the blockchain. Every single minting of a coinbase, and every single transaction ever made; from where, to where, at what point, how much etc. Also, AML already demands exchanges to able to supply identification for each account that ever does a BTCfiat exchange.
A banking goon wants cryptographic currency - a technological currency the banks cannot gain any control of - to be banned. How about that. What's next? A system for banning competition in business?
Someone obviously picked it up and decided NOT to bring it to the reception or Lost And Found. How would a label on the item matter? How were you thinking when you wrote this up, Tim?
With the fire not originating in anything connected to its electrical system, why are they assuming that the fire originated in/from the car at all? It sounds highly unlikely, and more like vacuous sensationalism.
Dig the power lines down instead of hanging them on pylons. In addition to pandering towards the senses of complaining house owners, it also solves the problem of critical outtages during storm seasons, which is why the Swedes are in the middle of dismantling pylons and moving their grid under the surface.
...their "The team" page doesn't mention a single software or hardware developer involved in creating the phone. Why aren't they worth to be on display along with the CEOs and whatnot?
Troll detected. But just in case... iOS 4 does actually run on the 3G, and Mavericks runs on as hold hardware as the last normal MB models prior to the Pro notation, which I believe were released in 2007.
"There are still lots of haters, talking about how there are better “alternatives” out there (alternatives usually being 3 or 4 times the cost, impossible to get, or apples to oranges)."
The MK808B, just to name one example out of many, isn't 3 or 4 times the cost, nor is it impossible to purchase. At $45 including shipping It's less than twice the cost. But why are people who widen their horizons, or require more computational/graphical power "haters"? That sounds pretty damned narrow-minded.
The "only" problem - and not really a little one - with OpenBSD for the specific purpose of acting as a wireless access point is that the state of its 802.11 drivers and stack is far from desirable.
First and foremost, there are currently only two WiFi chipsets worth looking at in the case of being used in "Host AP" mode on OpenBSD, and both of them have problems: the athn(4) driver for the Atheros family of chipsets is the only 802.11 driver in OpenBSD that supports powersaving clients when in Host AP mode - and believe me, this is very important for the routers' quality of service - but it suffers some as-of-yet resolved problem causing a notable amount of transmission errors for UDP traffic (no problems with TCP traffic, though). The ral(4) driver supporting the Ralink family of chipsets DOES NOT support powersaving clients currently, and it's a major problem, but the ral(4) driver is otherwise perfect, and in my personal experience the Ralink chipsets have the absolutely best signal quality, lowest transmission latency and least problems with signal distortion of all WiFi hardware I've used.
Secondly, there is the smaller problem of OpenBSD's 802.11 stack not yet having 11n support. For most users, me included, this won't matter at all.
I've been using OpenBSD profesionally and personally at home for about 14 years now, of which the past 7 years it has seen use in mine and friends' homes as a home router, often with WiFi capabilities. The OS itself is excellent for this and I'm most pleased with it for this particular purpose, but the 802.11 drivers' current state is plain and simply underdeveloped.
My advice to the original poster, or anyone else who is considering OpenBSD for a WiFi router, is to go with a card supported by the ral(4) driver ( incomplete device list here: http://www.openbsd.org/cgi-bin/man.cgi?query=ral&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html ), and try to live with the problems of lacking support for powersaving clients, or work around them by either disabling PSM on your clients if this is possible, or preventing the client devices' 802.11 chip from entering PSM. I've been using a ral(4) device for my OpenBSD router for a bit more than 5 years now, and, despite of its problems, it's for the moment definitely a better choice than an athn(4) device.
Slashdot Mirror
Not by GLSL as such, but it is supported in GLES 2.0.
...both have functionality for accessing (and saving) a compiled shader so that it can be loaded and used instantly on next run.
Just wait.
As will the ensuing debate be. The world is a rigged game.
It seems you're not familiar with the process of software development. You just don't issue one single commit containing a billion changes. It's a step by step process, for several reasons, most importantly the mechanic and iterative process of searching for bugs.
Still runs just as good as the day I bought it 10 years ago, incl. the HDD that came with it. The CCFL backlight in the screen has lost a lot of brightness output, though.
All of my old home computers I kept are still in 100% working conditions - a few C64s, Amigas, Ataris etc. In terms of more modern computing, my best example would be my home server/router which is a 14-15 years old Abit BF6 motherboard with a low-power passively cooled P3-600/133 and 512MB of RAM. This machine and its original 200W PSU saw 8-10 hours of use 5 days a week during 2000-2004, and from 2004 to this very day - 10 years - it has been running 24/7 as my home server/router, without failure. The only thing that has been replaced in that machine is the original HDD I bought with it, a 12GB Fujitsu drive, that died in 2010, after 10 years of service. They don't make 'em like they used to.
The cover art was delivering the message of the "wrist-worn/hand-held computer". It was neither joke nor prediction; it was symbolism.
Small explanation: what happens is that when the SSHd matches the user's login group successfully, it forcefully switches over to the internal sftp component instead of the default external subsystem, which in turn makes it possible to chroot the user to his/her home dir without having to place a plethora of system files in each user's home directory.
Proper support for power-saving clients comes down to buffering outgoing packets until the client asks the AP for them, rather then instantly sending them to the client which may or may not be asleep at that point. This is not a driver firmware issue, it's a fundamental stack problem and lies entirely in the hands of the OpenBSD developers.
There is no need for third-party tools for what you want to achieve. While the solution is a bit ungainly, all of it is already supported by OpenSSH and its sftp subsystem. This is how I configured things on my system:
/sbin/nologin as shell to deny them shell access. Their home directories should be owned by root:sftponly, and within the home dir you then create relevant user-controllable directories which should be owned by :sftponly.
/usr/libexec/sftp-server
First off, add a group that you call f.e. "sftponly". New users that are to be allowed only sftp access should have "sftponly" as their login group, and have
Secondly, the sshd_config magic that makes the whole charade work:
Subsystem sftp
Match Group sftponly
ForceCommand internal-sftp
ChrootDirectory %h
I've been using OpenBSD as my wireless home router, server and development platform since 2005, and can from 9 years of experience safely say that the current state of OpenBSD's Wi-Fi drivers and 802.11 stack is troubling. On one hand, most chipsets out there have rudimentary driver support in OpenBSD, including WPA2 and CCMP facilities. On the other hand, the 802.11 stack still lacks 11n support (minor problem) but what's much worse is that while only two of the drivers - ral(4) and athn(4) - state that they can handle power-saving clients when running in HostAP mode, none of them actually do it properly. None of the support ral(4) chipsets can handle power-saving clients despite what the ral(4) man page claims, and while athn(4) works slightly better it's still flaky with unreliable results, no matter what wireless chipset the client uses. The effect is that OpenBSD is useless as a wireless access point without having the clients pull one of several tricks available to avoid them from entering power-saving mode, as have been posted and explained by troubled users on the OBSD mailing lists regularly over the years.
I understand that Wi-Fi portions of OpenBSD aren't exactly prioritized, but are these issues even on the roadmap?
It's about the cost, not the coffee or the effort. High price tags attract people who suffer the "spender syndrome" - dishing out a lot of money on something even plain or generic gives these people a feeling of being above the average, being set aside from the rest of us, of enjoying something that is "exclusive" only to their kind.
It's like when you find the exact same piece of generic furniture sold at (but not designed by) IKEA in some upstreet furniture shop - IKEA would call it "ROBUST" (or whatever) and sell it for $89, while the other "boutique" will call it "Multimedia bench in Nordic pinewood" at thrice the pricetag. People with money will buy it, and they will feel like they did a better deal than paying $89 at IKEA. It's one of the oldest tricks in the book of retail.
Correct, it's "only" in OS X 10.9 and the latest iOS - OS X 10.8.5 and earlier are unaffected.
You're suffering a fundamental misunderstanding of the Bitcoin protocol. The entire currency as it stands at any point in time is contained within the blockchain. Every single minting of a coinbase, and every single transaction ever made; from where, to where, at what point, how much etc. Also, AML already demands exchanges to able to supply identification for each account that ever does a BTCfiat exchange.
A banking goon wants cryptographic currency - a technological currency the banks cannot gain any control of - to be banned. How about that. What's next? A system for banning competition in business?
This is how it starts.
Someone obviously picked it up and decided NOT to bring it to the reception or Lost And Found. How would a label on the item matter? How were you thinking when you wrote this up, Tim?
With the fire not originating in anything connected to its electrical system, why are they assuming that the fire originated in/from the car at all? It sounds highly unlikely, and more like vacuous sensationalism.
The argument isn't over power lines, it's over house owners on the countryside not wanting their scenery ruined.
Dig the power lines down instead of hanging them on pylons. In addition to pandering towards the senses of complaining house owners, it also solves the problem of critical outtages during storm seasons, which is why the Swedes are in the middle of dismantling pylons and moving their grid under the surface.
...their "The team" page doesn't mention a single software or hardware developer involved in creating the phone. Why aren't they worth to be on display along with the CEOs and whatnot?
Troll detected. But just in case... iOS 4 does actually run on the 3G, and Mavericks runs on as hold hardware as the last normal MB models prior to the Pro notation, which I believe were released in 2007.
"There are still lots of haters, talking about how there are better “alternatives” out there (alternatives usually being 3 or 4 times the cost, impossible to get, or apples to oranges)."
The MK808B, just to name one example out of many, isn't 3 or 4 times the cost, nor is it impossible to purchase. At $45 including shipping It's less than twice the cost. But why are people who widen their horizons, or require more computational/graphical power "haters"? That sounds pretty damned narrow-minded.
The "only" problem - and not really a little one - with OpenBSD for the specific purpose of acting as a wireless access point is that the state of its 802.11 drivers and stack is far from desirable.
First and foremost, there are currently only two WiFi chipsets worth looking at in the case of being used in "Host AP" mode on OpenBSD, and both of them have problems: the athn(4) driver for the Atheros family of chipsets is the only 802.11 driver in OpenBSD that supports powersaving clients when in Host AP mode - and believe me, this is very important for the routers' quality of service - but it suffers some as-of-yet resolved problem causing a notable amount of transmission errors for UDP traffic (no problems with TCP traffic, though). The ral(4) driver supporting the Ralink family of chipsets DOES NOT support powersaving clients currently, and it's a major problem, but the ral(4) driver is otherwise perfect, and in my personal experience the Ralink chipsets have the absolutely best signal quality, lowest transmission latency and least problems with signal distortion of all WiFi hardware I've used.
Secondly, there is the smaller problem of OpenBSD's 802.11 stack not yet having 11n support. For most users, me included, this won't matter at all.
I've been using OpenBSD profesionally and personally at home for about 14 years now, of which the past 7 years it has seen use in mine and friends' homes as a home router, often with WiFi capabilities. The OS itself is excellent for this and I'm most pleased with it for this particular purpose, but the 802.11 drivers' current state is plain and simply underdeveloped.
My advice to the original poster, or anyone else who is considering OpenBSD for a WiFi router, is to go with a card supported by the ral(4) driver ( incomplete device list here: http://www.openbsd.org/cgi-bin/man.cgi?query=ral&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html ), and try to live with the problems of lacking support for powersaving clients, or work around them by either disabling PSM on your clients if this is possible, or preventing the client devices' 802.11 chip from entering PSM. I've been using a ral(4) device for my OpenBSD router for a bit more than 5 years now, and, despite of its problems, it's for the moment definitely a better choice than an athn(4) device.