Fun fact -- OTA HDTV was for a long time one of the highest (technical) quality sources available. Fairly high-bit-rate MPEG2 can look VERY good, and generally doesn't suffer from the recompression artifacts of a cable or satellite provider working to maximize the number of channels rather than the quality of any particular channel. Yes, a good Blu-ray or stream can provide better quality now, but for a waiting-room situation, OTA HDTV is probably the best bet going.
Not that there will be anything to watch, but at least your daytime TV will only be crappy due to content.
Yes, Visual COBOL is a real thing: http://www.microfocus.com/downloads/visual-cobol-23-datasheet-215624.aspx
According to MF, '...supports Cloud, mobile,.NET and JVM, and a wide range of the latest environments.", so go out there and build your next Web 11.0 (we're up to that by now, right?) app in COBOL*
* MF is not responsible for any resulting substance abuse or psychiatric issues you may experience
Nice work, but it's pretty clear from the article that only the structural bits go together without fasteners (mostly). All of the interior finishes, doors, windows, etc. all clearly use conventional screws/nails. Not surprising, but not really the 'snap-together' house that the headline indicates, unless you plan to live in a bare structure open to the elements.
I'm shopping for a new laptop now for homework (elementary school), replacing a 2006 Dell D620 (C2D, 2GB RAM, upgraded to SSD). The only reason I'm replacing it is that it died. Otherwise, for what it did, it was still 'good enough'.
I'll grab another business-class laptop (yes, they are worth the premium IMHO), probably a factory refurb, and I bet that will be 'good enough' for schoolwork until the day it dies.
For anything that can be printed, print out a few copies on archival paper using an appropriate printer. Have photos professionally printed on Fuji Crystal Archive or better paper.
Unlike anything digital, we KNOW that paper will last several hundred years with only basic care.
Also, make more than one copy and store in more than one place.
Now, I'm just want to remember to NEVER borrow your phone:)
OTOH, what you've described is basically what corporate IT security has been about for years. It can be effective, but it's a bitch to maintain is will generally be discarded or circumvented in the name of 'convenience' the first time there is a trade-off between security and a shiny new feature.
My first thoughts, probably like many, were along the lines of "don't connect the TV to the Internet", but that is increasingly impractical as the article points out. Even more so, I can see why I might WANT my next smoke/CO detector, for example, to be connected and able to call the fire department if necessary. It might even be good if it had a mic/camera to allow the firemen to see/hear what is going on -- after all, if they take a look and see me standing there with a pole trying to jab the 'quiet' button and yelling 'false alarm!', they can avoid an expensive and time-wasting truck roll. Or, if they see smoke and people passed out on the floor, they can get it in gear KNOWING that there are lives on the line.
Basically, in short order we will (almost) all have bugged our own homes/cars/offices for perfectly good reasons. Or, if not for good reasons, than as a condition of our fire/casualty insurance policies.
Which means, unfortunately, that any technical fixes are attacking the wrong problem. What we need are behavioral/legislative fixes to make inappropriate access to these surveillance systems prohibited and punishable with real teeth. Punishments that breach the corporate veil, and are stricter in cases of official abuse than for 'ordinary hackers'. I wouldn't commence holding my breath for those laws, if I were you.
At any rate, go vote next week, and vote for 'less bad'. It's the best we can do.
Does this mean that DeWitt clauses (http://sqlmag.com/sql-server/devils-dewitt-clause) prohibiting publication of benchmark results are now invalid by statute in California? I'm sure that would be he very definition of 'unintended consequence', but I'd love for it to be true.
1. Meaningful, specific error/log messages when something goes wrong. 2. Accurate documentation of what those errors mean.
Most end-users won't read long or complicated documentation, business application in particular almost always require end-user training on how to use them --as implemented-- and --in accord with company practice/policy--, so generic docs are of limited value.
On the other hand, I sincerely miss the days when I could actually expect proper error codes and documentation thereof, and having that available would certainly influence a purchasing decision on my part.
Once you intentionally circumvent the security of the 'walled garden', I don't think you get to complain about vulnerabilities anymore.
To go with the ever-popular car analogy:
If a guy with a screwdriver is able to start my unmodified car without the smart-key being present, that is a security flaw.
If I modify my car to bypass the 'smart-key is present' requirement to start it, I don't get to complain when my car is stolen by some guy with a screwdriver.
OK, I've done BGP before, and I've never heard of anything smaller than a/24 being globally advertised -- most common router configurations won't even accept anything smaller.
That said, how is any network of any size supposed to protect itself again ISP outages other than multihoming? It clutters the routing table, but there is no other solution.
OTOH, if an IP-connected hot-water heater is the only kind on the market next time I need a new one, I'd prefer to have the 'securing it' worked out in advance, because I'm sure not going to do without.
I can't ever see secure firmware becoming the norm given the economics of consumer goods, so I think we're going to need much better firewalls than what we see in SOHO routers currently.
Port/address level control is spectacularly insufficient when everything runs on port 80, and nobody is going to spend time mapping out specific source/destination pairs for everything (The washer can talk to the dryer. The washer can talk to my smartphone. The dryer can talk to my smartphone...)
I'd like to see something like a home-PKCS standard where: 1. Any IOT device requires a client certificate supplied by the router 2. The router drops any traffic not signed by a recognized client certificate 3. The router's signing key must be kept on a seperate USB drive, and the WAN port is locked out if the USB drive is inserted.
To set up a new device on your home network you would:
1. Insert USB key into the router (WAN port shuts down) 2. Generate a new client certificate for the new device (push button "a") 3. Install the certificate on the new device (push button "b" on router and also on device within 60 seconds, enter PIN, something automated like that) 4. Remove USB key from router (WAN port comes back up)
The router will now pass signed traffic to/from your new device. Traffic not signed? No talking to IOT devices for you.
Yeah, key management sucks, but I bet it could be fairly easily automated for home use. It would take more thought and detail than I've outlined above, but should be doable. Unfortunately, that would require that everyone agree to follow the same standard for home-PKCS, and I can't see that happening either.
Plus cheap devices would have the crypto implemented badly, plus you wouldn't be able to turn on the microwave from your office, so on and so forth.
1. Versata produced software 'DCM' incorporating Ximpleware's GPLv2 licensed code. 2. Versata licensed DCM to Ameriprise, who then distributed copies to it's independent contractors. 3. Ximpleware's code is subject to patent claims in the USA, making distribution under GPLv2 impermissible, and Versata did not have a commercial license, making Versata's distribution of Ximpleware's code unlicensed (in the USA). 4. Ameriprise was not aware of (1) or (2) until discovery related to a lawsuit between Versata and Ameriprise.
If this is correct, I can see where Ximpleware has a copyright claim against Versata, but I don't see where Ximpleware has a copyright claim against Ameriprise for any distribution of DCM to it's contractors. Strictly speaking, I suppose Ameriprise did distribute copies of Ximpleware's code, but if they did so under good-faith belief that they had appropriately licensed DCM from Versata, I can not see it being reasonable to hold Ameriprise liable.
At the risk of a possible bad analogy, if Google included undocumented unlicensed code in Android, I would not consider it reasonable to hold each phone vendor liable for infringement, either.
I've got an S2RT also, and I have to agree with you. For me, the worst part is that when it's working well, it's absolutely brilliant. I'd go so far as to say that 95% of the time, it's everything I hoped it would be, and the other 5% it leaves me jaw-droppingly stunned at how fundamentally broken it is.
My two favorite bits 'o broken:
1. The screen periodically gets stuck in landscape, and nothing but a reboot will unstick it. 2. Three times now Bitlocker (which can not be turned off) has decided that it has the wrong key and will not even accept a recovery key. Time to factory-reset.
Have you ever tried to keep up with constitutes a "catch" in the NFL? Rules change all the time in pro sports, and players need to keep up. There may be good reasons why pro videogame players are locked to a particular game, but I doubt rule changes have much to do with it.
More likely, in my opinion, is that pro games excel at the game they first learned deeply enough to play "intuitively", and trying to switch is like trying to switch to another language. Do-able, sure, but requiring a long period of immersion to "speak like a native".
With any encryption scheme, key management is usually the biggest pain in the ass. No doubt, this is the biggest problem with implementing encryption for webmail.
Keeping my private key on a USB drive on my keychain could ALMOST work, in that on any desktop or laptop I could insert it to get to the key. For mobile, I think Yahoo will need to release a mail app that supports an easy & secure way to load your key.
Also - keying a passphrase on a moble device to open/sign/encrypt email will suck big time. This could be a great use for a fingerprint sensor on phones.
As neither a farmer nor a marine biologist, I should probably shut up, but hey, this is Slashdot!
I have to wonder how much use of synthetic fertilizer could be reduced by systematic crop rotation between corn and legumes to fix nitrogen naturally rather than dumping on the land? I suppose the price would probably be yields down/food prices up, but food is historically cheap at the moment.
I've been in the IT infrastructure business for years, and have always relied on physical destruction (shredding) of hard drives when disposing of old systems.
I can see where that may not be cost effective with leased systems, but I would take your experience as a warning to clean up after yourself and secure-wipe hard drives when your lease is up and not count on the datacenter to do it for you.
IANAL, but I also wonder who owns the data on a leased hard drive when the lease is up? If you improve an apartment or build a building on leased land, those improvements typically become the property of the owner when the lease is up. I wonder if that has been addressed with data in the absence of relevant contractual language?
Here's the thing: quality technical writing DOES require specialized skills. It also requires close collaboration with and cooperation from the dev team.
Having worked with a professional tech writer in the past, the process works something like this:
1. Dev team writes the software to meet the business requirements, keeping notes about which requirements are met completely, partial solutions, known bugs, etc. 2. Tech writer meets with dev team on a regular basis, developing draft documentation from dev team notes and business requirements following appropriate style guidelines. 3. At some point, a release is declared. Tech writer completes draft documentation draft for work completed for that release. 4. Dev team and tech writer reviews draft documentation together for completeness and correctness. 5. QA team implements the software in the QA environment PER THE DOCUMENTATION. -- this is the key part. If the documentation is insufficient to implement the software and/or the software does not work as documented, it is a bug. 6. Bug reports are filed against both the software and the documentation as necessary. 7. Release is ready when the software is acceptably debugged and works as documented.
Of course, this hardly ever happens anymore whether software is FOSS, commercial, or in-house, but I have see the process happen, and it is a beautiful thing when it does.
Slashdot Mirror
Fun fact -- OTA HDTV was for a long time one of the highest (technical) quality sources available. Fairly high-bit-rate MPEG2 can look VERY good, and generally doesn't suffer from the recompression artifacts of a cable or satellite provider working to maximize the number of channels rather than the quality of any particular channel. Yes, a good Blu-ray or stream can provide better quality now, but for a waiting-room situation, OTA HDTV is probably the best bet going.
Not that there will be anything to watch, but at least your daytime TV will only be crappy due to content.
Yes, Visual COBOL is a real thing: http://www.microfocus.com/downloads/visual-cobol-23-datasheet-215624.aspx
According to MF, '...supports Cloud, mobile, .NET and JVM, and a wide range of the latest environments.", so go out there and build your next Web 11.0 (we're up to that by now, right?) app in COBOL*
* MF is not responsible for any resulting substance abuse or psychiatric issues you may experience
Nice work, but it's pretty clear from the article that only the structural bits go together without fasteners (mostly). All of the interior finishes, doors, windows, etc. all clearly use conventional screws/nails. Not surprising, but not really the 'snap-together' house that the headline indicates, unless you plan to live in a bare structure open to the elements.
Yep - nailed it.
I'm shopping for a new laptop now for homework (elementary school), replacing a 2006 Dell D620 (C2D, 2GB RAM, upgraded to SSD). The only reason I'm replacing it is that it died. Otherwise, for what it did, it was still 'good enough'.
I'll grab another business-class laptop (yes, they are worth the premium IMHO), probably a factory refurb, and I bet that will be 'good enough' for schoolwork until the day it dies.
When I have a headless server/networking task to do, and don't want a side order of drama with my OS, NetBSD is my favorite way to just get it done.
Slackware was a huge step forward from SLS.
..professionally.
DOS
NetWare 2.15 - 6
SunOS
Solaris
VMS
Linux 0.99pl12 - current
ISC Unix
OS/2
Unixware
Windows NT 3.51 - current
Nothing changes.
The libc -> glibc switch was so much fun, that I think we should do it again in reverse!
For anything that can be printed, print out a few copies on archival paper using an appropriate printer. Have photos professionally printed on Fuji Crystal Archive or better paper.
Unlike anything digital, we KNOW that paper will last several hundred years with only basic care.
Also, make more than one copy and store in more than one place.
I was with you up to here:
... a basic fleshlight app...
Now, I'm just want to remember to NEVER borrow your phone :)
OTOH, what you've described is basically what corporate IT security has been about for years. It can be effective, but it's a bitch to maintain is will generally be discarded or circumvented in the name of 'convenience' the first time there is a trade-off between security and a shiny new feature.
My first thoughts, probably like many, were along the lines of "don't connect the TV to the Internet", but that is increasingly impractical as the article points out. Even more so, I can see why I might WANT my next smoke/CO detector, for example, to be connected and able to call the fire department if necessary. It might even be good if it had a mic/camera to allow the firemen to see/hear what is going on -- after all, if they take a look and see me standing there with a pole trying to jab the 'quiet' button and yelling 'false alarm!', they can avoid an expensive and time-wasting truck roll. Or, if they see smoke and people passed out on the floor, they can get it in gear KNOWING that there are lives on the line.
Basically, in short order we will (almost) all have bugged our own homes/cars/offices for perfectly good reasons. Or, if not for good reasons, than as a condition of our fire/casualty insurance policies.
Which means, unfortunately, that any technical fixes are attacking the wrong problem. What we need are behavioral/legislative fixes to make inappropriate access to these surveillance systems prohibited and punishable with real teeth. Punishments that breach the corporate veil, and are stricter in cases of official abuse than for 'ordinary hackers'. I wouldn't commence holding my breath for those laws, if I were you.
At any rate, go vote next week, and vote for 'less bad'. It's the best we can do.
Does this mean that DeWitt clauses (http://sqlmag.com/sql-server/devils-dewitt-clause) prohibiting publication of benchmark results are now invalid by statute in California? I'm sure that would be he very definition of 'unintended consequence', but I'd love for it to be true.
As an admin/IT manager, what I'd like to see is:
1. Meaningful, specific error/log messages when something goes wrong.
2. Accurate documentation of what those errors mean.
Most end-users won't read long or complicated documentation, business application in particular almost always require end-user training on how to use them --as implemented-- and --in accord with company practice/policy--, so generic docs are of limited value.
On the other hand, I sincerely miss the days when I could actually expect proper error codes and documentation thereof, and having that available would certainly influence a purchasing decision on my part.
Once you intentionally circumvent the security of the 'walled garden', I don't think you get to complain about vulnerabilities anymore.
To go with the ever-popular car analogy:
If a guy with a screwdriver is able to start my unmodified car without the smart-key being present, that is a security flaw.
If I modify my car to bypass the 'smart-key is present' requirement to start it, I don't get to complain when my car is stolen by some guy with a screwdriver.
OK, I've done BGP before, and I've never heard of anything smaller than a /24 being globally advertised -- most common router configurations won't even accept anything smaller.
That said, how is any network of any size supposed to protect itself again ISP outages other than multihoming? It clutters the routing table, but there is no other solution.
Well, yes, that actually IS a better idea.
OTOH, if an IP-connected hot-water heater is the only kind on the market next time I need a new one, I'd prefer to have the 'securing it' worked out in advance, because I'm sure not going to do without.
I can't ever see secure firmware becoming the norm given the economics of consumer goods, so I think we're going to need much better firewalls than what we see in SOHO routers currently.
Port/address level control is spectacularly insufficient when everything runs on port 80, and nobody is going to spend time mapping out specific source/destination pairs for everything (The washer can talk to the dryer. The washer can talk to my smartphone. The dryer can talk to my smartphone...)
I'd like to see something like a home-PKCS standard where:
1. Any IOT device requires a client certificate supplied by the router
2. The router drops any traffic not signed by a recognized client certificate
3. The router's signing key must be kept on a seperate USB drive, and the WAN port is locked out if the USB drive is inserted.
To set up a new device on your home network you would:
1. Insert USB key into the router (WAN port shuts down)
2. Generate a new client certificate for the new device (push button "a")
3. Install the certificate on the new device (push button "b" on router and also on device within 60 seconds, enter PIN, something automated like that)
4. Remove USB key from router (WAN port comes back up)
The router will now pass signed traffic to/from your new device. Traffic not signed? No talking to IOT devices for you.
Yeah, key management sucks, but I bet it could be fairly easily automated for home use. It would take more thought and detail than I've outlined above, but should be doable. Unfortunately, that would require that everyone agree to follow the same standard for home-PKCS, and I can't see that happening either.
Plus cheap devices would have the crypto implemented badly, plus you wouldn't be able to turn on the microwave from your office, so on and so forth.
Never mind, I give up.
If I read correctly:
1. Versata produced software 'DCM' incorporating Ximpleware's GPLv2 licensed code.
2. Versata licensed DCM to Ameriprise, who then distributed copies to it's independent contractors.
3. Ximpleware's code is subject to patent claims in the USA, making distribution under GPLv2 impermissible, and Versata did not have a commercial license, making Versata's distribution of Ximpleware's code unlicensed (in the USA).
4. Ameriprise was not aware of (1) or (2) until discovery related to a lawsuit between Versata and Ameriprise.
If this is correct, I can see where Ximpleware has a copyright claim against Versata, but I don't see where Ximpleware has a copyright claim against Ameriprise for any distribution of DCM to it's contractors. Strictly speaking, I suppose Ameriprise did distribute copies of Ximpleware's code, but if they did so under good-faith belief that they had appropriately licensed DCM from Versata, I can not see it being reasonable to hold Ameriprise liable.
At the risk of a possible bad analogy, if Google included undocumented unlicensed code in Android, I would not consider it reasonable to hold each phone vendor liable for infringement, either.
I've got an S2RT also, and I have to agree with you. For me, the worst part is that when it's working well, it's absolutely brilliant. I'd go so far as to say that 95% of the time, it's everything I hoped it would be, and the other 5% it leaves me jaw-droppingly stunned at how fundamentally broken it is.
My two favorite bits 'o broken:
1. The screen periodically gets stuck in landscape, and nothing but a reboot will unstick it.
2. Three times now Bitlocker (which can not be turned off) has decided that it has the wrong key and will not even accept a recovery key. Time to factory-reset.
Both pure software brokenness.
Have you ever tried to keep up with constitutes a "catch" in the NFL? Rules change all the time in pro sports, and players need to keep up. There may be good reasons why pro videogame players are locked to a particular game, but I doubt rule changes have much to do with it.
More likely, in my opinion, is that pro games excel at the game they first learned deeply enough to play "intuitively", and trying to switch is like trying to switch to another language. Do-able, sure, but requiring a long period of immersion to "speak like a native".
With any encryption scheme, key management is usually the biggest pain in the ass. No doubt, this is the biggest problem with implementing encryption for webmail.
Keeping my private key on a USB drive on my keychain could ALMOST work, in that on any desktop or laptop I could insert it to get to the key. For mobile, I think Yahoo will need to release a mail app that supports an easy & secure way to load your key.
Also - keying a passphrase on a moble device to open/sign/encrypt email will suck big time. This could be a great use for a fingerprint sensor on phones.
As neither a farmer nor a marine biologist, I should probably shut up, but hey, this is Slashdot!
I have to wonder how much use of synthetic fertilizer could be reduced by systematic crop rotation between corn and legumes to fix nitrogen naturally rather than dumping on the land? I suppose the price would probably be yields down/food prices up, but food is historically cheap at the moment.
I've been in the IT infrastructure business for years, and have always relied on physical destruction (shredding) of hard drives when disposing of old systems.
I can see where that may not be cost effective with leased systems, but I would take your experience as a warning to clean up after yourself and secure-wipe hard drives when your lease is up and not count on the datacenter to do it for you.
IANAL, but I also wonder who owns the data on a leased hard drive when the lease is up? If you improve an apartment or build a building on leased land, those improvements typically become the property of the owner when the lease is up. I wonder if that has been addressed with data in the absence of relevant contractual language?
It would be interesting to know if an unlocked AT&T phone moved to T-mobile's network suddenly lasts longer.
Here's the thing: quality technical writing DOES require specialized skills. It also requires close collaboration with and cooperation from the dev team.
Having worked with a professional tech writer in the past, the process works something like this:
1. Dev team writes the software to meet the business requirements, keeping notes about which requirements are met completely, partial solutions, known bugs, etc.
2. Tech writer meets with dev team on a regular basis, developing draft documentation from dev team notes and business requirements following appropriate style guidelines.
3. At some point, a release is declared. Tech writer completes draft documentation draft for work completed for that release.
4. Dev team and tech writer reviews draft documentation together for completeness and correctness.
5. QA team implements the software in the QA environment PER THE DOCUMENTATION. -- this is the key part. If the documentation is insufficient to implement the software and/or the software does not work as documented, it is a bug.
6. Bug reports are filed against both the software and the documentation as necessary.
7. Release is ready when the software is acceptably debugged and works as documented.
Of course, this hardly ever happens anymore whether software is FOSS, commercial, or in-house, but I have see the process happen, and it is a beautiful thing when it does.