Slackware was a huge step forward from SLS.
Slackware was a huge step forward from SLS.
NetWare 2.15 - 6
Linux 0.99pl12 - current
Windows NT 3.51 - current
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
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".
The Wright Bothers weren't the first to fly. They were just the first not to crash.