Well the GPL doesn't apply to anyone until they are distributing software--it clearly states one can *use* the software under the GPL without agreeing to the license until I distribute the software to others. Then of course the full force of the GPL applies. Thus I can run GPL'd code in proprietary software all I want as long as it never leaves my machine. Obviously the people who are distributing this kind of software would definitely be in violation of the GPL. But I don't really see how the UCITA applies to end users here in the case of GPL'd software.
Censorship, as defined in the constitution, is when the government suppresses speech against the government because it is negative. This is not censorship in any way. You can disagree with Verizon's decision, and voice opposition to it, even fight them in court if you want to, based on your contract or something.
When the majority of people oppose some particular form of expression and pass laws against it, it's not censorship as the minority who want this form of expression are still free to oppose the law and fight it in court, etc. Freedom really is the right to oppose something without fear of mortal repercussions.
To put it in perspective we need look no further than Zimbabwe for an example of what censorship really is. Let's get some perspective here.
Water injection isn't a scam at all. It's not a panacea either. You can probably get better mileage by driving less aggressively. But it definitely *does* increase efficiency, in some cars (older ones that are already very inefficient by modern standards) quite a bit.
Water injection isn't about putting water in the gas. It's about injecting water into the combustion chamber which regulates and slows the burning. Also the expanding steam helps extract just a bit more mechanical energy out of the heat from the combustion. I'd say the reason it's not mainstream is because we've already improved efficiencies a lot using other, easier methods. Modern engines are already doing other things to regulate combustion (fuel injection and fuel stratification, multiple ignitions per cycle, etc) that the benefit just doesn't make it worth their while. Consider that modern IC engines with the improvements I've mentioned are much more efficient and powerful than ever before. However our cars are heavier now, offsetting a lot of those gains. If we'd stick our modern engines and transmissions in the cars (hopefully not as ugly!) of the 70s, 50 MPG would be routine on highways. Anyway now that the low-hanging fruit has largely been picked, what we have left are more complicated things like water injection to try out. One problem water injection always had, besides the complication of pumping and injecting, was rust.
But don't discount it completely! You're right to suspect any dramatic claims. I'm thinking 10-20% improvement is all any one technology could possibly bring. But don't forget that at less than 18% mechanical efficiency from an IC engine, there's *lots* of room for improvement. Lots of efficiency improvement is somehow still possible. Obviously claiming to surpass 100% efficiency is BS!
One exciting thing being tried right now on big diesel engines is hydrogen injection. It's looking like it improves efficiency quite a bit (as much as 10%) while reducing emissions dramatically, which more than covers the energy needed to split water to get it on the fly. A 5-10% improvement in fuel economy on a truck is huge. Can equal savings of thousands of gallons of fuel a year. Of course the proponents of this technology note that efficiency improvements are much less on modern engines that already control combustion much better than they used to. But there still are some benifits (at least a few percent!) as well as major decreases in particulate and NOx emissions.
Why? AT&T gets their monthly fee (including the cost of data plan) every month no matter what the iPhone user does with his phone. The only thing that could possibly cause AT&T heartburn is VoIP calls over the edge network, which of course is prohibited by them and by Apple, probably as much for technical reasons as for political.
What are you saying? The wikipedia entry confirms OpenOffice.org is not written in Java. It uses Java for a variety of increasingly important things. So to reiterate. No, java isn't the sole cause of its slowdown. There are lots of other factors that can and should be dealt with. Java is just a strawman.
Wrong again. OpenOffice is written primarily in C++. It's surprising to see this myth perpetuated. Certain things like Base and various import export plugins require Java, but certainly not OpenOffice itself. Please stop spreading this kind of untruth. Besides being untrue, it's not relevant.
Mou misunderstand. MS is definitely solvent. That's not the point. MS is definitely not quite the powerhouse it once was in terms of sheer market influence. Perception has definitely turned against MS and all the money in the world won't change that. Remember that IBM is still a huge, very successful company and still very much "Big Blue." But no one would argue they control the PC (or general computer) market like they once did. MS does still have a monopoly in the area of OEM desktop OS's and Office suites, but that hold on the market is weakening. This doesn't mean that MS will go bankrupt by any stretch of the imagination.
No that's not true at all regarding the reason rpmforge exists. Dag's packages and rpmforge existed long before EPEL/Fedora. Now that the EPEL packages are quite sufficient when you add livna.org on Fedora, there is no reason to use Dag's packages with Fedora. Dag does support Fedora in some cases, but not all. That's also because most of Dag's packages are already in Fedora (clamav, etc). So rpmforge is really, in my opinion, only appropriate for RHEL or CentOS anyway, not Fedora.
As for EPEL incompatibility, we have freshrpms that is intended for use with Fedora, but since it violates the EPEL rules. Dependecy problems abound when using it so its use is not recommended at all. I tell Fedora uses to stick to livna as their only third-party repository.
On a RHEL or CentOS machine there are never any dependency conflicts with rpmforge. rpmforge guarantees that (report any cases of problems as bugs to Dag). However rpmforge does cover some stock rpms like rsync. While this does not introduce dependency problems, it is a concern to people who need RedHat support as they need to make sure they don't install any of Dag's packages that cover packages in the base distribution. Perhaps this is part of what you are referring to.
Dag Wieers is known to just about every user of RedHat Enterprise Linux and CentOS, because he and a few other people provide a ton of 3rd part packages that make life more bearable. See:http://dag.wieers.com/rpm/packages.php
He's also one of the people behind rpmforge, which tries to make a unified repo of 3rd party add-on packages. Previously there were a number of incompatible (dependencies and so forth) repositories like atrpms. Dag's work benefits all of us who use RHEL on a regular basis.
I'm assuming that Shuttleworth proposed that every enterprise distro synchronize the release versions of certain core packages like glibc, mysql, gcc, etc, so that it will be easier for vendors to target linux distros with their software releases. In theory it's a good idea, but not everyone has the same idea of what's important and what the right version to release is.
Definitely GPS-guided autonomous machines are coming soon.
The agricultural GPS system your link refers to is at present pretty primitive, and is just about guidance, really (although it can and does steer the tractor). It's incredibly useful though. I'm from a farm and all of our tractors and combines have these guidance systems now. They are limited to driving a particular path, then letting the operator turn around and drive towards the next path and then have GPS guidance lock on and steer the next path. That's how farmers get such straight rows now. The system can also do concentric circles, if you need to follow, say, pivot irrigation tracks. Using satellite guidance and the computer steering, during spring planting, an entire hour can be shaved off of a 130 acre piece. This translates into less seed wasted on overlaps, and less fuel wasted also. And given that equipment is very large now (sprayers are typically 100' wide or more), GPS guidance is the only way to drive, since a human can't accurately drive that far away from a previous pass. Even the best human drivers with a 30 foot wide outfit are at most accurate to 1-3 feet. Even the worst case GPS systems on tractors are about 6". Row croppers use towers and differential signals to get sub-inch accuracy.
But the human is very much still in the cab. Believe it or not John Deere's system has an EULA that you have to agree to when you active the system. You have to click "I agree" on the computer screen that you won't sue John Deere when your tractor runs over a house because you were too stupid to steer around it or turn at the end of a row.
So I wouldn't say the state of GPS-guidance systems is anywhere near the state of current UAV research systems. For one, UAVs can operate in 3-d space and it's much easier to avoid obstacles. On the ground it's a lot harder, especially when your movements are so constrained. I'd say we're still about 10-20 years away from an UGV (unmanned ground vehicle) that does full-blown obstacle avoidance and accomplishes missions.
If you know much about the state of UAVs these days, research and development is going mainly into autonomous vehicles. Human controllers are definitely in the loop, defining waypoints, orbits, and so forth, but they aren't being flown directly by pilots, unlike the current crop of *military* UAVs that are in operation right now. The goal of UAVs is to have the plane take off, fly a particular mission, do something, and then fly back and land. All without a pilot controlling it. This isn't some future thing. This is what UAVs in research labs are doing right now.
You can bet that the next generation of military UAVs are definitely unmanned and pilot-less, though not uncontrolled, agreed.
With commercial companies getting into UAV stuff for civilian purposes (monitoring land and crops, mapping developments for a contractor or something, etc), the FAA is probably right to worry. I am concerned that the FAA's typical over concern will negatively impact the hobby field where UAVs are being developed and flown at low altitudes for fun by quite a few rc computer hackers[1]. So many neat things are being done by hobbyists [2] and it would a real shame if the FAA shut them all down overly ridiculous concerns like terrorism.
I read e books on my ipod touch all the time. Some of that consists of content I download/scrape of some magazines I read that have on-line articles. Other books come from Project Gutenberg. The iPod Touch screen is incredibly sharp and readable. I find that having text in a continuous scrolling column allows me to read much much faster than normal books. However I still find real books easier on my eyes.
The Kindle's screen is definitely close to what I want, though. I want a 300-600dpi, paper white reflective display that basically emulates printed text on white paper. None of this light-emitting stuff for this application. Perhaps some day we'll just buy blank books with a couple hundred pages of e-paper and read the ebooks like normal books, turning pages and everything. Get to the end, just go back to the beginning and keep reading.
Odds are that real books will be around for a long, long time. No one format will replace them entirely but merely augment them.
Then you know how hard it is to setup LDAP, Kerberos, Samba, Radius, SASL, etc and get them playing together on Unix. Have you got Samba so that it can push domain password changes back through and change Kerberos? How about pam_ldap being able to change samba and kerberos passwords? Not so simple because so much glue is missing.
At the end of the day you or I can make these technologies on Unix do anything we want, but you have to admit the initial setup is very complicated compared to Active Directory (which can support posix and OS X clients fairly easily). What we're missing is some nice glue to bring it all together so that when someone installs RHEL they can say "I want directory services" and it installs all the components and provides a way for them to all work together. There needs to be an API that allows PAM and NSS to communicate with these core technologies at a higher level where things can be pushed down to the right modules. I should be able to run unix passwd and change my passwd all the way through the system (Samba, Kerberos, etc), just as on Active Directory I'd expect a user to be able to change a password via the domain and have it trickle through to the posix stuff they hack in to support Unix clients on Windows Server. I should be able to manage users through a consistent interface (be it command line or some kind of gui).
Except that SPF causes at least as many problems as it solves. That's why few people are really implementing it, or at least relying on it. SPF is at best a mere suggestion as to how to deal with a message. It fails to take into account things like relaying and people who are forced to use local ISP mail servers.
Yes working with OS X server in a non-Mac environment is painful, but not as painful as setting up LDAP from scratch for the uninitiated.
a) I'm not sure what you mean but either standard is acceptable. Most LDAP installations I've seen and done used the "uid=dfasdf" schema, since uids are natural keys. There were no configuration issues going from my old uid=blah,ou=People,dc=blah,dc=com to the Apple version of uid=blah,cn=users,dc=blah,dc=com, etc. PAM by default searchs the uid key so as long as that can find the user all is well
b) Yes, this is true, although we have yet to want to create a group that's not also a unix group. Typically our groups are used to help control file system access, and so unix groups make sense.
c) Yes, this is also a big problem. We find it easiest to delete the user and recreate it. There are tools for manipulating password server but it's a huge pain. I suppose I could write a script that could automate this.
d) This is true, but the mac-only fields are few in number and really don't matter that much, at least on Tiger Server.
We've built a web-based system on top of all this that overcomes a number of these limitations. Because our web-based system is somewhat complete (although very specific to our install, unfortunately), we're actually migrating away from OpenDirectory and back to a regular LDAP/Kerberos on Linux system. We're still keeping OS X server around as we can always sync information into that can serve our mac users.
So yes. we've definitely come around to the idea that OpenDirectory is a great idea but Apple's implementation sucks. Maybe Samba 4 and Fedora Directory will do a better job. I think I might agree with your last statement too. If you're already using unix servers and LDAP, stick with it; it's easier to integrate Apple into that. But the idea was good.
And I doubt you've ever worked with Samba in an LDAP environment. Kerberos as authentication for Windows clients in conjunction with Samba does *not* work easily. Most of people I know give up on the idea and just revert to Samba hashes in LDAP. It is possible, but it's not an easy or "out-of-box" task on any distro. Even getting LDAP and Kerberos together is a challenge that's not well-documented and there are many other problems (see below).
I certainly have more experience in this entire area than most, and would be interested to hear your experiences. My LDAP is tied into Kerberos for authentication, but most LDAP-enabled applications on the planet (including our printers) do not support SASL binds in anyway. Only simple binds, plain-text over SSL. So I have userPassword fields set to SASL pass-through. This eliminates the need to store some password information in LDAP, but not all.
Even still, though, I have to change the password in three places: 1. Samba hashes in LDAP 2. Kerberos 3. SASL database (used in conjunction with Radius, etc)
Hence changing passwords on the unix command line with "passwd" does not work.
It's still a huge, non-integrated mess. It's not "just peachy" in any sense of the word. There is a *lot* of work to be done to improve the situation of directory services on Linux.
Sounds like someone who's a) never used OS X server and b) never had to wrangle OpenLDAP, Kerberos, Samba, and SASL on a regular Linux server.
It's fine to say, stick with BSD or Linux, but they only ship with pieces of the puzzle, not integrated at all. This is especially apparent in the Directory Services area. Sad to say but nothing except Apple's offering comes close to competing with ActiveDirectory. OpenLDAP itself is great (and we use it to serve up information on thousands of users), but it's just one piece. Then you have Kerberos, Samba (with its own password schemes), SASL Authd, Radius, etc. With BSD and OpenLDAP, Kerberos, and Samba, you can get it working pretty well but you still have to deal with changing passwords in two or more places, different password expiry schemes that all have to be kludged together sometimes with spit and baling wire.
Apple's solution, on paper, is more ideal. Directory Services exports both an authentication layer and an authorization layer, welded together in a common API and common admining tools. Change the user's password and the password server, which integrates SASL, Kerberos, NTPassword, and LMPassword hashes, everything, no matter what protocol, keeps everything in sync. There are no passwords stored in LDAP at all, which is as it should be. Samba, PAM, SASL clients, etc, all talk to the password server. Contrast this with most LDAP installations on nix. There's a userPassword field, which can have any number of hash types in it. Then there's the shadowAccount attributes for password expiry. Then there's sambaNtPassword, and SambaLMPassword fields with their own hashes. Then there's Kerberos off to the side, never really integrated (except for certain kinds of SASL binds). It's honestly a mess. I hope that in the future, other products like Fedora Directory will take care of many of these problems. Samba 4 certainly will be a huge leap forward. One which I hope (with it's integrated LDAP system) will finally compete with ActiveDirectory.
In short, what Apple has done with OS X Server is a tantalizing idea of what we could do in the *nix server space if we put our minds to it. Sadly Apple's solution is lacking in many areas including just being half-baked and their enterprise support is non-existent. They have also never published their APIs to develop pam-DirectoryService and nss-DirectoryService for conventional Unix OS's, either, which is very short-sighted. So Apple's solution has promise, but tends to fall down outside of the base cases. But the standard alternatives are also very bad.
For those who have either never used BASIC (other than VB) or have preconceived false notions about the family of langauges, check out the open source FreeBASIC compiler, from http://freebasic.net./ It supports much of the old QuickBASIC syntax, as well as a much cleaner, modern syntax that supports object-oriented programming, pointers, etc, all with the goodness of a good runtime library that has (and has always had from the early days of BASIC) a good dynamic string library.
Yes GOTO is still in the language (as it is in C where it is extremely useful in a handful of critical cases), but you won't see line number or even line labels much. Instead you get a fully structured language that's easily equal to C. FreeBASIC produces object code compatible with any C library and can leverage things like GTK.
It was kind of fun to port some of my old QB code (graphics code even) to run under FreeBASIC. FB's runtime emulates the older graphics modes (Screen 9 anyone?) on modern X11 or Windows systems. Kind of fun to run the old nibbles.bas game again, natively compiled to a linux app (console or X11... you decide).
These days, of course, I stick to Python. But rather than mixing C and Python for speed, I probably should look into writing python extensions in FB.
And two cents is all it is. Many people are running OS X 10.5.x on their regular PCs, on a certain set of hardware, which does, by the way, include certain gigabyte motherboards. Two of my acquaintances are using the Kalyway install disk and EFI boot loader hack. Recently we also installed OS X 10.5.1 on a Dell Optiplex GX755, which worked pretty well, including the updates (so I've been told).
I'm not sure why you're so convinced this is a fake. What does Gigabyte have to do with anything? They simply make motherboards and sell them to end users and OEMS. They don't have to agree to anything. It just turns out that Gigabyte motherboards seem to run OS X really well.
In short this is nothing but another whitebox pc manufacturer who happens to be illegally pre-installing OSX86 on it.
I'm quite astounded by folks who, when faced with a picture or video of something they don't understand or have never before seen immediately cry "fake!"
The iis.net forum is full of very interesting posts by windows admins. One guy was hacked no less than 3 times! Each time he just restored his database and thought all was well, and wondered how those dang hackers kept getting in. He even changed his passwords!
This is definitely not how most unix admins would react. If a machine is compromised (via whatever source) then a simple data restore is never good enough, unix admins know. The original vector must be identified and stopped. It's quite the contrast.
I've always maintained that a good unix guy can do anything on windows with a bit of training, but a windows guy will generally be completely out of his element in unix. Not sure why, exactly, as best practices are best practices.
Being from a cold weather climate where I can see several applications for outdoor applications, I am curious as to what they mean by "down to the freezing point (0 degrees F)." Surely they meant 0 Celsius.
I am running today's OS X! Your comment about DOS on a computer is just messed up. It's not at all similar. My 5 year old laptop runs Leopard. And still gets 4-5 hours of battery life. It's not fast on compilation, chokes on youtube, but it runs as well as it every did.
Slashdot Mirror
Umm, what part of "toll number" did you miss?
Well the GPL doesn't apply to anyone until they are distributing software--it clearly states one can *use* the software under the GPL without agreeing to the license until I distribute the software to others. Then of course the full force of the GPL applies. Thus I can run GPL'd code in proprietary software all I want as long as it never leaves my machine. Obviously the people who are distributing this kind of software would definitely be in violation of the GPL. But I don't really see how the UCITA applies to end users here in the case of GPL'd software.
Censorship, as defined in the constitution, is when the government suppresses speech against the government because it is negative. This is not censorship in any way. You can disagree with Verizon's decision, and voice opposition to it, even fight them in court if you want to, based on your contract or something.
When the majority of people oppose some particular form of expression and pass laws against it, it's not censorship as the minority who want this form of expression are still free to oppose the law and fight it in court, etc. Freedom really is the right to oppose something without fear of mortal repercussions.
To put it in perspective we need look no further than Zimbabwe for an example of what censorship really is. Let's get some perspective here.
Water injection isn't a scam at all. It's not a panacea either. You can probably get better mileage by driving less aggressively. But it definitely *does* increase efficiency, in some cars (older ones that are already very inefficient by modern standards) quite a bit.
Water injection isn't about putting water in the gas. It's about injecting water into the combustion chamber which regulates and slows the burning. Also the expanding steam helps extract just a bit more mechanical energy out of the heat from the combustion. I'd say the reason it's not mainstream is because we've already improved efficiencies a lot using other, easier methods. Modern engines are already doing other things to regulate combustion (fuel injection and fuel stratification, multiple ignitions per cycle, etc) that the benefit just doesn't make it worth their while. Consider that modern IC engines with the improvements I've mentioned are much more efficient and powerful than ever before. However our cars are heavier now, offsetting a lot of those gains. If we'd stick our modern engines and transmissions in the cars (hopefully not as ugly!) of the 70s, 50 MPG would be routine on highways. Anyway now that the low-hanging fruit has largely been picked, what we have left are more complicated things like water injection to try out. One problem water injection always had, besides the complication of pumping and injecting, was rust.
But don't discount it completely! You're right to suspect any dramatic claims. I'm thinking 10-20% improvement is all any one technology could possibly bring. But don't forget that at less than 18% mechanical efficiency from an IC engine, there's *lots* of room for improvement. Lots of efficiency improvement is somehow still possible. Obviously claiming to surpass 100% efficiency is BS!
One exciting thing being tried right now on big diesel engines is hydrogen injection. It's looking like it improves efficiency quite a bit (as much as 10%) while reducing emissions dramatically, which more than covers the energy needed to split water to get it on the fly. A 5-10% improvement in fuel economy on a truck is huge. Can equal savings of thousands of gallons of fuel a year. Of course the proponents of this technology note that efficiency improvements are much less on modern engines that already control combustion much better than they used to. But there still are some benifits (at least a few percent!) as well as major decreases in particulate and NOx emissions.
Why? AT&T gets their monthly fee (including the cost of data plan) every month no matter what the iPhone user does with his phone. The only thing that could possibly cause AT&T heartburn is VoIP calls over the edge network, which of course is prohibited by them and by Apple, probably as much for technical reasons as for political.
What are you saying? The wikipedia entry confirms OpenOffice.org is not written in Java. It uses Java for a variety of increasingly important things. So to reiterate. No, java isn't the sole cause of its slowdown. There are lots of other factors that can and should be dealt with. Java is just a strawman.
Wrong again. OpenOffice is written primarily in C++. It's surprising to see this myth perpetuated. Certain things like Base and various import export plugins require Java, but certainly not OpenOffice itself. Please stop spreading this kind of untruth. Besides being untrue, it's not relevant.
Mou misunderstand. MS is definitely solvent. That's not the point. MS is definitely not quite the powerhouse it once was in terms of sheer market influence. Perception has definitely turned against MS and all the money in the world won't change that. Remember that IBM is still a huge, very successful company and still very much "Big Blue." But no one would argue they control the PC (or general computer) market like they once did. MS does still have a monopoly in the area of OEM desktop OS's and Office suites, but that hold on the market is weakening. This doesn't mean that MS will go bankrupt by any stretch of the imagination.
Nevermind about the EPEL stuff. You are correct that rpmforge is not a part of EPEL for RHEL 4 or 5, although rpmforge existed long before EPEL.
No that's not true at all regarding the reason rpmforge exists. Dag's packages and rpmforge existed long before EPEL/Fedora. Now that the EPEL packages are quite sufficient when you add livna.org on Fedora, there is no reason to use Dag's packages with Fedora. Dag does support Fedora in some cases, but not all. That's also because most of Dag's packages are already in Fedora (clamav, etc). So rpmforge is really, in my opinion, only appropriate for RHEL or CentOS anyway, not Fedora.
As for EPEL incompatibility, we have freshrpms that is intended for use with Fedora, but since it violates the EPEL rules. Dependecy problems abound when using it so its use is not recommended at all. I tell Fedora uses to stick to livna as their only third-party repository.
On a RHEL or CentOS machine there are never any dependency conflicts with rpmforge. rpmforge guarantees that (report any cases of problems as bugs to Dag). However rpmforge does cover some stock rpms like rsync. While this does not introduce dependency problems, it is a concern to people who need RedHat support as they need to make sure they don't install any of Dag's packages that cover packages in the base distribution. Perhaps this is part of what you are referring to.
Dag Wieers is known to just about every user of RedHat Enterprise Linux and CentOS, because he and a few other people provide a ton of 3rd part packages that make life more bearable. See:http://dag.wieers.com/rpm/packages.php
He's also one of the people behind rpmforge, which tries to make a unified repo of 3rd party add-on packages. Previously there were a number of incompatible (dependencies and so forth) repositories like atrpms. Dag's work benefits all of us who use RHEL on a regular basis.
I'm assuming that Shuttleworth proposed that every enterprise distro synchronize the release versions of certain core packages like glibc, mysql, gcc, etc, so that it will be easier for vendors to target linux distros with their software releases. In theory it's a good idea, but not everyone has the same idea of what's important and what the right version to release is.
Definitely GPS-guided autonomous machines are coming soon.
The agricultural GPS system your link refers to is at present pretty primitive, and is just about guidance, really (although it can and does steer the tractor). It's incredibly useful though. I'm from a farm and all of our tractors and combines have these guidance systems now. They are limited to driving a particular path, then letting the operator turn around and drive towards the next path and then have GPS guidance lock on and steer the next path. That's how farmers get such straight rows now. The system can also do concentric circles, if you need to follow, say, pivot irrigation tracks. Using satellite guidance and the computer steering, during spring planting, an entire hour can be shaved off of a 130 acre piece. This translates into less seed wasted on overlaps, and less fuel wasted also. And given that equipment is very large now (sprayers are typically 100' wide or more), GPS guidance is the only way to drive, since a human can't accurately drive that far away from a previous pass. Even the best human drivers with a 30 foot wide outfit are at most accurate to 1-3 feet. Even the worst case GPS systems on tractors are about 6". Row croppers use towers and differential signals to get sub-inch accuracy.
But the human is very much still in the cab. Believe it or not John Deere's system has an EULA that you have to agree to when you active the system. You have to click "I agree" on the computer screen that you won't sue John Deere when your tractor runs over a house because you were too stupid to steer around it or turn at the end of a row.
So I wouldn't say the state of GPS-guidance systems is anywhere near the state of current UAV research systems. For one, UAVs can operate in 3-d space and it's much easier to avoid obstacles. On the ground it's a lot harder, especially when your movements are so constrained. I'd say we're still about 10-20 years away from an UGV (unmanned ground vehicle) that does full-blown obstacle avoidance and accomplishes missions.
If you know much about the state of UAVs these days, research and development is going mainly into autonomous vehicles. Human controllers are definitely in the loop, defining waypoints, orbits, and so forth, but they aren't being flown directly by pilots, unlike the current crop of *military* UAVs that are in operation right now. The goal of UAVs is to have the plane take off, fly a particular mission, do something, and then fly back and land. All without a pilot controlling it. This isn't some future thing. This is what UAVs in research labs are doing right now.
You can bet that the next generation of military UAVs are definitely unmanned and pilot-less, though not uncontrolled, agreed.
With commercial companies getting into UAV stuff for civilian purposes (monitoring land and crops, mapping developments for a contractor or something, etc), the FAA is probably right to worry. I am concerned that the FAA's typical over concern will negatively impact the hobby field where UAVs are being developed and flown at low altitudes for fun by quite a few rc computer hackers[1]. So many neat things are being done by hobbyists [2] and it would a real shame if the FAA shut them all down overly ridiculous concerns like terrorism.
[1] http://www.rcgroups.com/uav-unmanned-aerial-vehicles-238/
[2] http://paparazzi.enac.fr/wiki/index.php/Main_Page
I read e books on my ipod touch all the time. Some of that consists of content I download/scrape of some magazines I read that have on-line articles. Other books come from Project Gutenberg. The iPod Touch screen is incredibly sharp and readable. I find that having text in a continuous scrolling column allows me to read much much faster than normal books. However I still find real books easier on my eyes.
The Kindle's screen is definitely close to what I want, though. I want a 300-600dpi, paper white reflective display that basically emulates printed text on white paper. None of this light-emitting stuff for this application. Perhaps some day we'll just buy blank books with a couple hundred pages of e-paper and read the ebooks like normal books, turning pages and everything. Get to the end, just go back to the beginning and keep reading.
Odds are that real books will be around for a long, long time. No one format will replace them entirely but merely augment them.
Then you know how hard it is to setup LDAP, Kerberos, Samba, Radius, SASL, etc and get them playing together on Unix. Have you got Samba so that it can push domain password changes back through and change Kerberos? How about pam_ldap being able to change samba and kerberos passwords? Not so simple because so much glue is missing.
At the end of the day you or I can make these technologies on Unix do anything we want, but you have to admit the initial setup is very complicated compared to Active Directory (which can support posix and OS X clients fairly easily). What we're missing is some nice glue to bring it all together so that when someone installs RHEL they can say "I want directory services" and it installs all the components and provides a way for them to all work together. There needs to be an API that allows PAM and NSS to communicate with these core technologies at a higher level where things can be pushed down to the right modules. I should be able to run unix passwd and change my passwd all the way through the system (Samba, Kerberos, etc), just as on Active Directory I'd expect a user to be able to change a password via the domain and have it trickle through to the posix stuff they hack in to support Unix clients on Windows Server. I should be able to manage users through a consistent interface (be it command line or some kind of gui).
Except that SPF causes at least as many problems as it solves. That's why few people are really implementing it, or at least relying on it. SPF is at best a mere suggestion as to how to deal with a message. It fails to take into account things like relaying and people who are forced to use local ISP mail servers.
Yes working with OS X server in a non-Mac environment is painful, but not as painful as setting up LDAP from scratch for the uninitiated.
a) I'm not sure what you mean but either standard is acceptable. Most LDAP installations I've seen and done used the "uid=dfasdf" schema, since uids are natural keys. There were no configuration issues going from my old uid=blah,ou=People,dc=blah,dc=com to the Apple version of uid=blah,cn=users,dc=blah,dc=com, etc. PAM by default searchs the uid key so as long as that can find the user all is well
b) Yes, this is true, although we have yet to want to create a group that's not also a unix group. Typically our groups are used to help control file system access, and so unix groups make sense.
c) Yes, this is also a big problem. We find it easiest to delete the user and recreate it. There are tools for manipulating password server but it's a huge pain. I suppose I could write a script that could automate this.
d) This is true, but the mac-only fields are few in number and really don't matter that much, at least on Tiger Server.
We've built a web-based system on top of all this that overcomes a number of these limitations. Because our web-based system is somewhat complete (although very specific to our install, unfortunately), we're actually migrating away from OpenDirectory and back to a regular LDAP/Kerberos on Linux system. We're still keeping OS X server around as we can always sync information into that can serve our mac users.
So yes. we've definitely come around to the idea that OpenDirectory is a great idea but Apple's implementation sucks. Maybe Samba 4 and Fedora Directory will do a better job. I think I might agree with your last statement too. If you're already using unix servers and LDAP, stick with it; it's easier to integrate Apple into that. But the idea was good.
And I doubt you've ever worked with Samba in an LDAP environment. Kerberos as authentication for Windows clients in conjunction with Samba does *not* work easily. Most of people I know give up on the idea and just revert to Samba hashes in LDAP. It is possible, but it's not an easy or "out-of-box" task on any distro. Even getting LDAP and Kerberos together is a challenge that's not well-documented and there are many other problems (see below).
I certainly have more experience in this entire area than most, and would be interested to hear your experiences. My LDAP is tied into Kerberos for authentication, but most LDAP-enabled applications on the planet (including our printers) do not support SASL binds in anyway. Only simple binds, plain-text over SSL. So I have userPassword fields set to SASL pass-through. This eliminates the need to store some password information in LDAP, but not all.
Even still, though, I have to change the password in three places:
1. Samba hashes in LDAP
2. Kerberos
3. SASL database (used in conjunction with Radius, etc)
Hence changing passwords on the unix command line with "passwd" does not work.
It's still a huge, non-integrated mess. It's not "just peachy" in any sense of the word. There is a *lot* of work to be done to improve the situation of directory services on Linux.
Sounds like someone who's a) never used OS X server and b) never had to wrangle OpenLDAP, Kerberos, Samba, and SASL on a regular Linux server.
It's fine to say, stick with BSD or Linux, but they only ship with pieces of the puzzle, not integrated at all. This is especially apparent in the Directory Services area. Sad to say but nothing except Apple's offering comes close to competing with ActiveDirectory. OpenLDAP itself is great (and we use it to serve up information on thousands of users), but it's just one piece. Then you have Kerberos, Samba (with its own password schemes), SASL Authd, Radius, etc. With BSD and OpenLDAP, Kerberos, and Samba, you can get it working pretty well but you still have to deal with changing passwords in two or more places, different password expiry schemes that all have to be kludged together sometimes with spit and baling wire.
Apple's solution, on paper, is more ideal. Directory Services exports both an authentication layer and an authorization layer, welded together in a common API and common admining tools. Change the user's password and the password server, which integrates SASL, Kerberos, NTPassword, and LMPassword hashes, everything, no matter what protocol, keeps everything in sync. There are no passwords stored in LDAP at all, which is as it should be. Samba, PAM, SASL clients, etc, all talk to the password server. Contrast this with most LDAP installations on nix. There's a userPassword field, which can have any number of hash types in it. Then there's the shadowAccount attributes for password expiry. Then there's sambaNtPassword, and SambaLMPassword fields with their own hashes. Then there's Kerberos off to the side, never really integrated (except for certain kinds of SASL binds). It's honestly a mess. I hope that in the future, other products like Fedora Directory will take care of many of these problems. Samba 4 certainly will be a huge leap forward. One which I hope (with it's integrated LDAP system) will finally compete with ActiveDirectory.
In short, what Apple has done with OS X Server is a tantalizing idea of what we could do in the *nix server space if we put our minds to it. Sadly Apple's solution is lacking in many areas including just being half-baked and their enterprise support is non-existent. They have also never published their APIs to develop pam-DirectoryService and nss-DirectoryService for conventional Unix OS's, either, which is very short-sighted. So Apple's solution has promise, but tends to fall down outside of the base cases. But the standard alternatives are also very bad.
For those who have either never used BASIC (other than VB) or have preconceived false notions about the family of langauges, check out the open source FreeBASIC compiler, from http://freebasic.net./ It supports much of the old QuickBASIC syntax, as well as a much cleaner, modern syntax that supports object-oriented programming, pointers, etc, all with the goodness of a good runtime library that has (and has always had from the early days of BASIC) a good dynamic string library.
Yes GOTO is still in the language (as it is in C where it is extremely useful in a handful of critical cases), but you won't see line number or even line labels much. Instead you get a fully structured language that's easily equal to C. FreeBASIC produces object code compatible with any C library and can leverage things like GTK.
It was kind of fun to port some of my old QB code (graphics code even) to run under FreeBASIC. FB's runtime emulates the older graphics modes (Screen 9 anyone?) on modern X11 or Windows systems. Kind of fun to run the old nibbles.bas game again, natively compiled to a linux app (console or X11... you decide).
These days, of course, I stick to Python. But rather than mixing C and Python for speed, I probably should look into writing python extensions in FB.
And two cents is all it is. Many people are running OS X 10.5.x on their regular PCs, on a certain set of hardware, which does, by the way, include certain gigabyte motherboards. Two of my acquaintances are using the Kalyway install disk and EFI boot loader hack. Recently we also installed OS X 10.5.1 on a Dell Optiplex GX755, which worked pretty well, including the updates (so I've been told).
I'm not sure why you're so convinced this is a fake. What does Gigabyte have to do with anything? They simply make motherboards and sell them to end users and OEMS. They don't have to agree to anything. It just turns out that Gigabyte motherboards seem to run OS X really well.
In short this is nothing but another whitebox pc manufacturer who happens to be illegally pre-installing OSX86 on it.
I'm quite astounded by folks who, when faced with a picture or video of something they don't understand or have never before seen immediately cry "fake!"
The iis.net forum is full of very interesting posts by windows admins. One guy was hacked no less than 3 times! Each time he just restored his database and thought all was well, and wondered how those dang hackers kept getting in. He even changed his passwords!
This is definitely not how most unix admins would react. If a machine is compromised (via whatever source) then a simple data restore is never good enough, unix admins know. The original vector must be identified and stopped. It's quite the contrast.
I've always maintained that a good unix guy can do anything on windows with a bit of training, but a windows guy will generally be completely out of his element in unix. Not sure why, exactly, as best practices are best practices.
In 2009 you mean?
Being from a cold weather climate where I can see several applications for outdoor applications, I am curious as to what they mean by "down to the freezing point (0 degrees F)." Surely they meant 0 Celsius.
I am running today's OS X! Your comment about DOS on a computer is just messed up. It's not at all similar. My 5 year old laptop runs Leopard. And still gets 4-5 hours of battery life. It's not fast on compilation, chokes on youtube, but it runs as well as it every did.
So yes. I am comparing modern generations.