So far, I've tried various operating systems for a VM for Web browsing. Believe it or not, XP is the best. If FB stalls or the VM has issues, a quick rollback to a known good snapshot (one that hasn't touched the Net except for updates.) It performs well in 512 MB of RAM for most Web browsing. That way, if FB decides to hang, you are just a few minutes (less if you snapshot the VM while it is on and suspended.)
Regardless of quality, would anyone want to drive a vehicle like that on most roads and risk getting rear-ended by someone texting and didn't notice (or care) about the situation around them? Some stuff is just too valuable to be driven unless the cost to re-buy is chump change.
To a lesser extent, this car reminds me somewhat of the pre-iPhone cellular industry about 10 years ago. Nokia and others sometimes had models put out which were not as breathtakingly advanced, but instead, had silver/gold cases, inlaid gems or crystals.
These days, expensive with smartphones usually means something that is an average device, but ends up blinged out. The only smartphone I've seen which has tech advances possibly worth the premium would be the Chairman by Ulysse Nardin, with its wind-up system to power the phone. Of course, last time I checked, it is running Android 2.2.
Very true. A seller isn't forced to do it. However, it is CYA, and almost all reasonable firearm sellers really don't want to sell stuff to someone who might be a felon. Getting known for putting crime guns on the street is bad for business as a dealer. Very bad.
No, it isn't 100%, but it requires collusion between a buyer and seller. However, it narrows a gap without a single new law, and does so in a fairly easily implementable manner that guards privacy.
The ironic thing is that the "loophole" can be easily closed by cryptographic means.
1: User goes to the government's website, gets cleared for a purchase, and gets a QR code they can download or print.
2: User takes QR code to show.
3: Seller scans QR code with offline app (no need for Internet access since the app just decodes the QR code and runs a gpg check on the signature, then prints out the owner's name), it checks it against the g'vt's public key, and if it verifies, the buyer is able to purchase a firearm. If not, no sale.
Result: No laws changed, no new laws need to be added, the "gun show loophole" is closed, nobody has to know how many or what type of firearms the buyer has, and nobody who is not expressly cleared to purchase one can get their hands on one.
Home Depot and Lowe's is another. However, the way those two compete is that one is slightly cheaper, the other is slightly more upscale. This allows them to have the same market, but yet still be slightly different.
The problem is that Box seems to be falling behind Dropbox when it comes to acceptance. On most iOS apps, if there is a cloud provider, it will be Dropbox, then iCloud. On Android, it is Dropbox.
What Box could do to keep up is have some method on Android phones to do data transfers similar to iCloud. For example, when I use an app to move some large documents into iCloud, the app returns automatically. The actual transfer on the device is then handled in the background. If Box could do this, it would keep them up to speed.
Another thing Box could do for differentating themselves is to have client encryption built into the client, either with a passphrase or by grabbing a hash from a keyfile. That way, the actual data is stored on the server encrypted, someone who manages to get access to the Box account will only be able to access the encrypted data, but for apps with the proper keyfile or passphrase loaded, reading/writing stuff is completely transparent.
Having the client have its own encryption may not stop the big guys who can force Box to push out backdoors, but it will definitely stop intruders who managed to slurp a password or two.
Of course, it would be nice to have a public/private separation. Anything stored on the private side cannot be shared, no way, no how. Anything on the public side can be either private, shared with someone, or anyone with a link. That way, one knows that data stored will stay private no matter what.
There are always the old standbys, RedHat/CentOS/Fedora/Oracle Linux, Slackware, and Gentoo. I don't know how they fare in the "easy to use" department (mainly because I tend to do custom installs, so what I consider "easy to use" is not what a newcomer to the Linux world would consider "easy to use".)
I mainly use the RedHat variants because they are the staple in the enterprise (I can prove to the auditors that a few of the commercial distros like RedHat, SuSE, and Oracle Linux are FIPS/Common Criteria certified for example.) However, they may not be as easy to pick up as Ubuntu or Debian.
It is a decent app, although the fact that it wouldn't allow one to move a document to another editor or app killed it for me. For a business with BYOD, that feature is useful (to keep work documents in one place), but for me, it didn't work out well, since I might want to stash a PDF E-mailed to me onto my local samba server without forwarding it to another account.
I will use the stock ROM to check that all the phone's features (camera, bluetooth, Wi-Fi, etc.) work. Then, the phone gets loaded with a new ROM, either CM, or if not, I'll see about a "stock" ROM sans the junk. Usually I go through a few ROMs as people get used to the device and write nifty stuff.
It boils down to personal preference. Apple's apps are decent, but if there is a feature you want (browser client certificates, gpg plugins), you are SOL. Android might have default apps which might be "meh" level, but they can be replaced. Tired of the stock keyboard? Download Swype. Tired of the stock music player? There are plenty of other players. Want a better SMS client? Plenty out there on the Play Store.
A good example is mail. With my Android phone, I like keeping my "professional" E-mail account with the custom domain separated from my casual accounts. For the Exchange stuff, it gets a dedicated TouchDown app. For my "secure" E-mail account (one which is only used for private communication), it gets its own K-9 app. Everything else goes on the stock app.
Why would root be a security risk? Unlike iOS where the entire security model is dependent on how secure the jails are (and if JB-ed, all bets are off), Android functions exactly the same.
The only way it would be an issue is if one clicks "yes" when the superuser app asks for permission. Even then, newer apps have a su permission (android.permission.ACCESS_SUPERUSER) request that one sees on installing, so an app that doesn't explicitly state on installing it might use root privs won't ever get through the superuser app anyway, or it will give a big warning.
Root comes into handy a lot of times, especially if one wants to use a utility like EncFS for securing data, backup application files completely with Titanium Backup, or just ensure a high bandwidth app only uses a Wi-Fi connection.
I am going to propose that wealth really needs to be measured in energy. The more energy available, that can be converted into almost anything. Garbage can be "boiled" via thermal depolymerization into usable monomers, mine tailings can be processed and the toxic metals isolated. Even very inefficient processes like making hydrogen from water can be made useful. Of course, BitCoin mining requires a good amount of wattage, especially at this late date in the mining curve.
What would be ideal would be a more extended partnership with local book sellers. It would be nice if the local book seller could sell a hardcopy with the ability to grab the Amazon ebook edition as well for a couple dollars more than just the hardcopy itself. This way, both Amazon and the local store benefit from each other.
This might even be doable (assuming Amazon could get the permission from publishers) with used books as well.
What I would like is some standardized way for recovering an account, but something decentralized, so one site doesn't hold the keys to everyone's city.
Maybe some option of signing a nonce with one's private key, using a OTP keyfob, or reading a text message, or perhaps a combination of the above might be good.
I've wondered about an "oh shit" recovery key. This would be a USB dongle that only receives power from the USB port, since it would not need a battery. It would be similar to the old SecurID "calculator" keyfobs, except very basic. Hit one button to enter in the device's private key for that site. Hit another button, type the website's challenge on the keypad, type the device's response into the web browser, and the account is re-activated. Maybe even allow for multiples of these.
That way, if someone forgot everything, all they would need is that physical key which never comes online.
Of course, physical security becomes a major issue, but I wonder if that might be a good way to do things for non-tech savvy people, since the concept of a "master key" is understandable... use it when needed, keep it locked up otherwise.
I could be wrong though, and a break-in would not just mean physical stuff taken, but free access to an account. Of course, the recovery device can have a PIN on it, but then what happens if that is forgotten... perhaps an escrow service?
I wonder about using XenDesktop for a solution for something like that. That way, there is one VM with Windows Server 2003 or XP, and it isn't taking up space and resources on everyone's desktop.
I've dealt with companies that even now, still require IE6, and actually use JScript hacks to check if a browser is masquerading. Those, I just fire up an XP VM, use that to browse the web, then when done, shut the VM down, drop the redo log. In fact, the VM is stored on one volume read-only and changes are stored in a working directory, so there isn't any chance of contamination.
Very true. However, if worse comes to worst, I can go into a meeting room. Of course, it can be done, but the telescope and transceiver are a lot less common than a smartphone with a BT or Wi-Fi antenna.
For a Diffie-Hellman key exchange, it is ideal. One can watch the exchange take place, but it would be very difficult to MITM it. Implementing NFC to have two devices validate their public keys is a lot simpler than trying to do the same over NFC, or even audio.
Nail, head hit. What is needed is to teach the basics about languages, so jumping from perl to java to ABAP to Scheme to Ada is a relatively minor item (you figure out syntax, variable convention, etc... perhaps procedural versus lambda based, etc.)
After these basics, one can learn Java and be a Java dev, but when that peters out, it doesn't take much to grab an O'Reilly guide and start programming in PHP, Python, or perhaps even back to perl.
In most languages [1], a ring buffer is a ring buffer. A queue is a queue, a stack is a stack.
What I dislike are these "tech schools" who teach something so dated that it means nothing. For example, "fiber optics". What is that? Is that level 1 networking? Is that physically laying down the cable and lighting it up? Is that not looking down a single mode fiber with remaining eye? CS degrees tend to be more generic, but at least the concepts stay constant, barring a fundamental change to architecture [2].
Of course, it would be nice to merge CS and MIS, where one learns both the programming aspect as well as the human factor that is needed in IT to survive.
[1]: Good luck trying to do a double-ended queue in LOGO, so I say "most" to cover those.
[2]: I've always wanted a set of FPGAs on a machine so when security sensitive code is executed, there is a Harvard architecture "core" made for that job, and after the tasks are done, it is back to the von Neumann world. This wouldn't be fast, but it definitely would help in the security department.
I think it is because some people confuse "Chinese" with the Han race. It is similar to how Muslims are always classified as Arabs, even though Persians are a different ethnic group.
I liked IrDA because it was secure. If you wanted to copy data privately between one device and another, you placed the IR ports nearby each other, and started a transfer. Unlike Bluetooth, an eavesdropping device has to not be just present, but close enough (within a couple feet) of both devices in order to get any significant data.
Plus, IrDA is simple. It takes a lot less to get it communicating data than even a basic USB slot, so it can be a method to upgrade/configure a microcontroller without having to have a physical connection to it.
This isn't new technology either. Ages ago (circa 1989), there was a LocalTalk [1] adapter that mounted on top of a cubicle. You mounted all the adapters, focused them all on a wall that all of them could see, a green light would come on when they were happy, then tightened them in place. From there, all the machines would yak happily with each other via infrared. This worked quite well in a cube farm, and one could use infrared adapters so traffic could be carried to a different room.
I'm sure "LiFi" has some improvements with it, but fundamentally, this was done before.
[1]: LocalTalk as in Apple's networking solution which was a different L1 media than Ethernet. Of course, there was LocalTalk as a protocol which helped confuse things even more.
I've seen some expensive versions of software like lastpass that store the root/Administrator/enable passwords for machines in a database, provides physical protection, allows access to control to groups, etc. For a company with a lot of people it is the way to go.
One software maker had a feature where if a junior admin needed a root password to a box normally not allowed to him/her, the software would allow them to access it (assuming that access was granted beforehand), then senior admins and management were notified... pretty much similar to storing the root password in a sealed desk envelope. I totally forgot what it was called though.
Fuel cells are getting there, but it seems to be a matter of getting a market for it before they start becoming mainstream.
For RV-ers, we already have Truma (Europe only) who makes propane fuel cells, and EFOY, who makes methanol based cells, both coupled with 12 volt charge controllers for RV use. These don't put out a lot of wattage (250 watt/hours), but are good enough to keep batteries topped off when one runs an RV furnace (where the fans take 7-10 amp-hours), or a laptop computer.
Fuel cells are making the absorption refrigerator obsolete (and for those RV-ing, that is a big thing), so I'm hoping economies of scale bring the price down.
Slashdot Mirror
So far, I've tried various operating systems for a VM for Web browsing. Believe it or not, XP is the best. If FB stalls or the VM has issues, a quick rollback to a known good snapshot (one that hasn't touched the Net except for updates.) It performs well in 512 MB of RAM for most Web browsing. That way, if FB decides to hang, you are just a few minutes (less if you snapshot the VM while it is on and suspended.)
Regardless of quality, would anyone want to drive a vehicle like that on most roads and risk getting rear-ended by someone texting and didn't notice (or care) about the situation around them? Some stuff is just too valuable to be driven unless the cost to re-buy is chump change.
To a lesser extent, this car reminds me somewhat of the pre-iPhone cellular industry about 10 years ago. Nokia and others sometimes had models put out which were not as breathtakingly advanced, but instead, had silver/gold cases, inlaid gems or crystals.
These days, expensive with smartphones usually means something that is an average device, but ends up blinged out. The only smartphone I've seen which has tech advances possibly worth the premium would be the Chairman by Ulysse Nardin, with its wind-up system to power the phone. Of course, last time I checked, it is running Android 2.2.
Very true. A seller isn't forced to do it. However, it is CYA, and almost all reasonable firearm sellers really don't want to sell stuff to someone who might be a felon. Getting known for putting crime guns on the street is bad for business as a dealer. Very bad.
No, it isn't 100%, but it requires collusion between a buyer and seller. However, it narrows a gap without a single new law, and does so in a fairly easily implementable manner that guards privacy.
Quick followup: The QR code has a fairly short expiration time (1 day to a week.)
The ironic thing is that the "loophole" can be easily closed by cryptographic means.
1: User goes to the government's website, gets cleared for a purchase, and gets a QR code they can download or print.
2: User takes QR code to show.
3: Seller scans QR code with offline app (no need for Internet access since the app just decodes the QR code and runs a gpg check on the signature, then prints out the owner's name), it checks it against the g'vt's public key, and if it verifies, the buyer is able to purchase a firearm. If not, no sale.
Result: No laws changed, no new laws need to be added, the "gun show loophole" is closed, nobody has to know how many or what type of firearms the buyer has, and nobody who is not expressly cleared to purchase one can get their hands on one.
Win all the way around.
I remember IV holders being made ten years ago on a stereolithography machine... so hospital stuff has been done for a while.
Home Depot and Lowe's is another. However, the way those two compete is that one is slightly cheaper, the other is slightly more upscale. This allows them to have the same market, but yet still be slightly different.
The problem is that Box seems to be falling behind Dropbox when it comes to acceptance. On most iOS apps, if there is a cloud provider, it will be Dropbox, then iCloud. On Android, it is Dropbox.
What Box could do to keep up is have some method on Android phones to do data transfers similar to iCloud. For example, when I use an app to move some large documents into iCloud, the app returns automatically. The actual transfer on the device is then handled in the background. If Box could do this, it would keep them up to speed.
Another thing Box could do for differentating themselves is to have client encryption built into the client, either with a passphrase or by grabbing a hash from a keyfile. That way, the actual data is stored on the server encrypted, someone who manages to get access to the Box account will only be able to access the encrypted data, but for apps with the proper keyfile or passphrase loaded, reading/writing stuff is completely transparent.
Having the client have its own encryption may not stop the big guys who can force Box to push out backdoors, but it will definitely stop intruders who managed to slurp a password or two.
Of course, it would be nice to have a public/private separation. Anything stored on the private side cannot be shared, no way, no how. Anything on the public side can be either private, shared with someone, or anyone with a link. That way, one knows that data stored will stay private no matter what.
There are always the old standbys, RedHat/CentOS/Fedora/Oracle Linux, Slackware, and Gentoo. I don't know how they fare in the "easy to use" department (mainly because I tend to do custom installs, so what I consider "easy to use" is not what a newcomer to the Linux world would consider "easy to use".)
I mainly use the RedHat variants because they are the staple in the enterprise (I can prove to the auditors that a few of the commercial distros like RedHat, SuSE, and Oracle Linux are FIPS/Common Criteria certified for example.) However, they may not be as easy to pick up as Ubuntu or Debian.
It is a decent app, although the fact that it wouldn't allow one to move a document to another editor or app killed it for me. For a business with BYOD, that feature is useful (to keep work documents in one place), but for me, it didn't work out well, since I might want to stash a PDF E-mailed to me onto my local samba server without forwarding it to another account.
I will use the stock ROM to check that all the phone's features (camera, bluetooth, Wi-Fi, etc.) work. Then, the phone gets loaded with a new ROM, either CM, or if not, I'll see about a "stock" ROM sans the junk. Usually I go through a few ROMs as people get used to the device and write nifty stuff.
It boils down to personal preference. Apple's apps are decent, but if there is a feature you want (browser client certificates, gpg plugins), you are SOL. Android might have default apps which might be "meh" level, but they can be replaced. Tired of the stock keyboard? Download Swype. Tired of the stock music player? There are plenty of other players. Want a better SMS client? Plenty out there on the Play Store.
A good example is mail. With my Android phone, I like keeping my "professional" E-mail account with the custom domain separated from my casual accounts. For the Exchange stuff, it gets a dedicated TouchDown app. For my "secure" E-mail account (one which is only used for private communication), it gets its own K-9 app. Everything else goes on the stock app.
Why would root be a security risk? Unlike iOS where the entire security model is dependent on how secure the jails are (and if JB-ed, all bets are off), Android functions exactly the same.
The only way it would be an issue is if one clicks "yes" when the superuser app asks for permission. Even then, newer apps have a su permission (android.permission.ACCESS_SUPERUSER) request that one sees on installing, so an app that doesn't explicitly state on installing it might use root privs won't ever get through the superuser app anyway, or it will give a big warning.
Root comes into handy a lot of times, especially if one wants to use a utility like EncFS for securing data, backup application files completely with Titanium Backup, or just ensure a high bandwidth app only uses a Wi-Fi connection.
I am going to propose that wealth really needs to be measured in energy. The more energy available, that can be converted into almost anything. Garbage can be "boiled" via thermal depolymerization into usable monomers, mine tailings can be processed and the toxic metals isolated. Even very inefficient processes like making hydrogen from water can be made useful. Of course, BitCoin mining requires a good amount of wattage, especially at this late date in the mining curve.
What would be ideal would be a more extended partnership with local book sellers. It would be nice if the local book seller could sell a hardcopy with the ability to grab the Amazon ebook edition as well for a couple dollars more than just the hardcopy itself. This way, both Amazon and the local store benefit from each other.
This might even be doable (assuming Amazon could get the permission from publishers) with used books as well.
What I would like is some standardized way for recovering an account, but something decentralized, so one site doesn't hold the keys to everyone's city.
Maybe some option of signing a nonce with one's private key, using a OTP keyfob, or reading a text message, or perhaps a combination of the above might be good.
I've wondered about an "oh shit" recovery key. This would be a USB dongle that only receives power from the USB port, since it would not need a battery. It would be similar to the old SecurID "calculator" keyfobs, except very basic. Hit one button to enter in the device's private key for that site. Hit another button, type the website's challenge on the keypad, type the device's response into the web browser, and the account is re-activated. Maybe even allow for multiples of these.
That way, if someone forgot everything, all they would need is that physical key which never comes online.
Of course, physical security becomes a major issue, but I wonder if that might be a good way to do things for non-tech savvy people, since the concept of a "master key" is understandable... use it when needed, keep it locked up otherwise.
I could be wrong though, and a break-in would not just mean physical stuff taken, but free access to an account. Of course, the recovery device can have a PIN on it, but then what happens if that is forgotten... perhaps an escrow service?
I wonder about using XenDesktop for a solution for something like that. That way, there is one VM with Windows Server 2003 or XP, and it isn't taking up space and resources on everyone's desktop.
I've dealt with companies that even now, still require IE6, and actually use JScript hacks to check if a browser is masquerading. Those, I just fire up an XP VM, use that to browse the web, then when done, shut the VM down, drop the redo log. In fact, the VM is stored on one volume read-only and changes are stored in a working directory, so there isn't any chance of contamination.
I'd just push the cert out from AD as a trusted root and be done with it... or at least have an internal CA.
Very true. However, if worse comes to worst, I can go into a meeting room. Of course, it can be done, but the telescope and transceiver are a lot less common than a smartphone with a BT or Wi-Fi antenna.
For a Diffie-Hellman key exchange, it is ideal. One can watch the exchange take place, but it would be very difficult to MITM it. Implementing NFC to have two devices validate their public keys is a lot simpler than trying to do the same over NFC, or even audio.
Nail, head hit. What is needed is to teach the basics about languages, so jumping from perl to java to ABAP to Scheme to Ada is a relatively minor item (you figure out syntax, variable convention, etc... perhaps procedural versus lambda based, etc.)
After these basics, one can learn Java and be a Java dev, but when that peters out, it doesn't take much to grab an O'Reilly guide and start programming in PHP, Python, or perhaps even back to perl.
In most languages [1], a ring buffer is a ring buffer. A queue is a queue, a stack is a stack.
What I dislike are these "tech schools" who teach something so dated that it means nothing. For example, "fiber optics". What is that? Is that level 1 networking? Is that physically laying down the cable and lighting it up? Is that not looking down a single mode fiber with remaining eye? CS degrees tend to be more generic, but at least the concepts stay constant, barring a fundamental change to architecture [2].
Of course, it would be nice to merge CS and MIS, where one learns both the programming aspect as well as the human factor that is needed in IT to survive.
[1]: Good luck trying to do a double-ended queue in LOGO, so I say "most" to cover those.
[2]: I've always wanted a set of FPGAs on a machine so when security sensitive code is executed, there is a Harvard architecture "core" made for that job, and after the tasks are done, it is back to the von Neumann world. This wouldn't be fast, but it definitely would help in the security department.
I think it is because some people confuse "Chinese" with the Han race. It is similar to how Muslims are always classified as Arabs, even though Persians are a different ethnic group.
I liked IrDA because it was secure. If you wanted to copy data privately between one device and another, you placed the IR ports nearby each other, and started a transfer. Unlike Bluetooth, an eavesdropping device has to not be just present, but close enough (within a couple feet) of both devices in order to get any significant data.
Plus, IrDA is simple. It takes a lot less to get it communicating data than even a basic USB slot, so it can be a method to upgrade/configure a microcontroller without having to have a physical connection to it.
That's just for malware, which arguably is the most reliable software made these days.
This isn't new technology either. Ages ago (circa 1989), there was a LocalTalk [1] adapter that mounted on top of a cubicle. You mounted all the adapters, focused them all on a wall that all of them could see, a green light would come on when they were happy, then tightened them in place. From there, all the machines would yak happily with each other via infrared. This worked quite well in a cube farm, and one could use infrared adapters so traffic could be carried to a different room.
I'm sure "LiFi" has some improvements with it, but fundamentally, this was done before.
[1]: LocalTalk as in Apple's networking solution which was a different L1 media than Ethernet. Of course, there was LocalTalk as a protocol which helped confuse things even more.
I've seen some expensive versions of software like lastpass that store the root/Administrator/enable passwords for machines in a database, provides physical protection, allows access to control to groups, etc. For a company with a lot of people it is the way to go.
One software maker had a feature where if a junior admin needed a root password to a box normally not allowed to him/her, the software would allow them to access it (assuming that access was granted beforehand), then senior admins and management were notified... pretty much similar to storing the root password in a sealed desk envelope. I totally forgot what it was called though.
Fuel cells are getting there, but it seems to be a matter of getting a market for it before they start becoming mainstream.
For RV-ers, we already have Truma (Europe only) who makes propane fuel cells, and EFOY, who makes methanol based cells, both coupled with 12 volt charge controllers for RV use. These don't put out a lot of wattage (250 watt/hours), but are good enough to keep batteries topped off when one runs an RV furnace (where the fans take 7-10 amp-hours), or a laptop computer.
Fuel cells are making the absorption refrigerator obsolete (and for those RV-ing, that is a big thing), so I'm hoping economies of scale bring the price down.