How about dumb users that suffer from 0-day exploits in their up-to-date OS ? I doubt they'll be happy if they are kicked off the internet for something they can do nothing about, and can only get back online after they've waited for a bugfix and reinstalled their entire machine.
Talk about out of context! I proposed two solution that could take out botnets that do NOT rely on either: * completely eliminating both security flaws * dumb users that install malicious software because some web popup told them to.
0-day exploits falls into the former. Yes, they'd get destroyed, alterered, or kicked off by their ISP in the proposed solutions. Tough luck, but if your computer is part of a botnet, it deserves to be kicked off (at the very least). Fix it and then ask to have your service re-established.
FWIW, ISP's already do this to protect the MPAA/RIAA and even have a 3 strikes rule where you'll never get back on, and there's even a chance you'll get sued in that case. Everything is in place to be able to do this though, as I noted, ISP's are unlikely to do it as it'll cost them money and customers.
You can only kill the malware that is behind these DDoS's by completely eliminating security flaws in software....
Wrong.
There's multiple times of DDoS's. Let's get that out of the way.... we're talking about botnet based DDoS here. Solutions are different for other types.
Given a botnet attacking one or more targeted hosts, it's relatively easy to identify a large number of the hosts involved in the attack. While illegal, once you have that, it's quite feasible infiltrate at least a subset of those hosts. Go from there and infiltrate the botnet as a whole (determine command and control stuff, determine other bots, take over for a short period of time). While you own it, kill all the hosts (something between full wipe of the HDD, just disabling their ability to get online, and doing a surgical removal of any malware and securing the system... I'd lean towards the middle of those).
If one entity did such a thing, they'd be labeled as an awful and horrible hacker by many, so it's not going to happen.
A legal, but much slower way with loads more red tape, would be to involve the users ISP's. Give them the lists of hosts, and have them ID the owners then immediately terminate their service. That's going to cost the ISP money to do it, and it's a loss of revenue losing those customers, so this isn't going to happen unless our laws change to require this.
Both those are technically possible though, unlike completely eliminating both security flaws and dumb users that install malicious software because some web popup told them to.
Just because the airlines claim to be broke doesn't mean they are. Football teams in the USA also claim they lose money all the time.
THIS! If you run a business and show loads of profit, you'll pay loads of taxes on said profit. In addition, especially in this case, users would be pissed and complaining that they were being overcharged. Work the books so that you have a tight margin, and even run in the red a couple years at a time (at least), and you'll be better off as a company. In this case, they can also milk extra money from the government since we couldn't do without airlines.
All that said, it is an industry that is extremely expensive to maintain. Lots of room for failure, and even more room to lose money within the company (whether on purpose or not).
Anyone know someone that owns a small plane? The gas cost for a short-ish flight, split between the 2-4 passengers, can run more than a seat on a normal airline. That's not even counting the cost of the plain, maintenance, hanger fees, etc etc etc. It's pretty amazing we can fly for the prices we have now.
Zediva was shutdown because like Aero they tried to work around the laws to skip paying for a license from the content provider.
They were purchasing regular DVDs and renting them in violation of the DVD license. Rental DVDs require a totally different license.
[bolded by me] That part is not true AFAICT. See The Consumer Video Sales/Rental Amendment of 1983. In that case, the doctrine of first sale was upheld, and you can do whatever you want with something that you have legitimately acquired a copy of (ex. VHS or DVD). Just one of many examples: http://thinkprogress.org/ygles...
Thank you for this but: a) if they're using that for real time chat, that's not the complete solution. How does it all tie together? b) if they're not using it for real time chat, then that doesn't answer the question really.
Even for simple status updates and such, "OTP on a microSD" is still not a complete answer. If I had my OTP stored anywhere, then it'd also be encrypted. Then there's the matter of how to decrypt the OTP wherever one happens to be. All very solvable, but a detailed doc of all the parts and how they fit together and what tools are used with them etc etc would be nice to see.
The details are what I was hoping to see. As it is, the article(s) seem pretty useless (though they had that potential).
It will be as successful as the "legalize marijuana" petition.
Is that really the example you want to use? Is the answer, "fairly successful"?
23 states and District of Columbia currently have laws legalizing marijuana in some form. 4 states have legalized it for recreational use (6 in 2015). Many states have eliminated or greatly reduced penalties for small amounts of it. Population-wise, and electoral-college-wise, I believe we are well past 50%.
mod parent up. Rulings like those in Aareo and Zediva's cases almost make it seem like normal DVD rentals and TiVO's will be the next on the chopping block. Of course, they tried, but somehow (luckily) those won.
Why the hell Zediva got shut down is beyond me. Aereo was actually more likely to be shut down than Zediva (it could be argued that Aereo put some load on the existing system to sell a rebroadcast to users that were not possible customers of said broadcasts which, while technically should have skirted the laws, was a fairly obvious attempt at getting something for nothing and charging for it while playing tricks to avoid the law). I still thought it was a good service, but it was obviously a kludge.
Ideally, at least in my view, the content owners, or those they've licensed to, would make all their content available at a reasonable rate over the internet. The aggregation and post processing should, IMO, happen at the customer premise. Just like TiVO, but pull the streams from various sources rather than requiring cable TV, satellite TV, Hulu, Netflix, Amazon, Vudu, etc etc etc. In addition, metadata should be free (ie. tv guide data) from anyone broadcasting anything over anything - I mean, why the hell not?
My prediction is that things will continue on what is now the obvious path. Re: see iTunes and mp3's. Essentially, some balance/semi-standard will be set for cost-per-show and cost-per-movie, and a handful of big companies will get access to nearly the entire library, and people will cut back on pirating and kludges such as aereo will no longer be profitable. And yes, dvd sales will drop as quickly as cd sales, and cable tv subscriptions will slowly decline, but that's all just the transport medium. Cut down on cable TV subscriptions, and cable may be able to be more competitive with FiOS for internet access:-)
There's a whole lot of comments here saying this is stupid, obvious, not surprising, etc, and pointing out other clients that have used (and still use) XMPP (jabber).
The one potentially interesting bit that brought me here... what are they using for encryption?
I'm assuming they have TLS enabled from client to server, and from server to server. The details for that layer are not very important to me, though I'd still be interested to know. The end-to-end encryption used, that's what I'd be most curious to hear about. There's a lot of apps and plugins and such that boast end-to-end encryption, but there is little interoperability AFAICT. There's a fairly wide variety of implementations and specs (and lack thereof). OTR may be the best known one (http://en.wikipedia.org/wiki/Off-the-Record_Messaging). IMO, what it uses seems somewhat dated with respect to all the SSL/TLS issues that came to light this past year. Ex, OTR uses:
* Diffie-Hellman key exchange with 1536 bit group size. (is this ADH, static DH, DHE, ECDH, ECDHE, etc) * AES symmetric key with 128 bit key length (AES 256 is more the norm now, and there are certainly lots of other alternatives) * SHA-1 hash function (SHA1 is deprecated in many situations, and SHA256 and other stronger hash functions are readily available) * forward secrecy (that's good... but I wonder if it's using similar and well tested methods such as used in current PFS TLS implementations) * NO support for multi-user group chat
I'm betting there's better and/or more updated things out there. Seems OTR could be updated fairly easily (define new protocol version and use different set of stuff in the various places in the protocol), but what is it that others that are extremely paranoid are using?
Dude, with 2800 chairs per person, I could build every man woman and child a chairhouse, guest chairhouse, summer chairhouse and chairhouse cabin.
Build log cabin-ish structures, rather than drywall covered toothpicks that are so common today. I'm betting that'd get is a lot closer to being effective, but it's still a pretty stupid/naive idea.
We've destroyed a ton of rain forest. No amount of planting trees in our backyards is going to make up for that, especially when most backyards used to have trees, or already do. To tackle the problem with vegetation, we'd need to reverse the rain forest deforestation, cultivate arid lands (deserts and dustbowls), and probably look into ocean based stuff (algae etc... oceans covering more of the earth than anything else, have they all have water and sunlight readily available).
Personally, I'm a bit curious (but not curious enough to look it up) how long it'll take, or how rich in CO2 we'd need to be, before we see giant pre-historic-ish trees make a comeback. I'm guessing we'll all be dead before that happens, but I like to think the earth will manage just fine with huge CO2 levels, even flourish.
That's a really good idea, but... cue inane "coprorations are people" counter-argument.
It's a crap idea. If patents could not be transferred, then if person X worked for company Y, and then went to company Z, they'd be taking the patents with them with no means to leave them with the company that was using them. Furthermore, it doesn't solve anything... company X can buy company Y and then give themselves free licensing rights and have their legal team take over suing others just as companies do now. If you're thinking, "you wouldn't be allowed to only buy the patents", that's trivial to work around... sell off all the other parts of the business, leaving only the patents, then sell everything that's left (just the patents). Regardless, one could still assign full rights to manage said patent portfolio to some 3rd party company. That would be nearly impossible to avoid - just consider the 3rd party as a bunch of lawyers and have them do all the same stuff those 3rd parties are doing today, simply leaving the actual patent assignment where it was.
How about we modify that solution a little... (NOTE: this is a proposal, not a statement of the current situation)
#1. corporations are not people (not sure which way you meant that counter-argument to read). #2. corporations can not hold patents #3. people can transfer patents to other people, or sell licensing agreements with terms of their choosing
FWIW, I do not claim that would solve the problem either. I think that's better than the current situation, but it's still fairly easy to manipulate and end up in a functionally identical situation. Someone patents something while working for a company; company draws up paperwork to have a zero cost licensing agreement with that employee (or maybe gives them a bonus or something... up to them); company and employee could agree to sign over the rights to some other person at the company; company would essentially own the patent. There'd be more ways to get a patent out of the loop, but with the right paperwork in place it wouldn't matter.
There are a bunch of real problems with the current system, but the ownership thing is really more of a symptom of those issues than an actual problem.
* software patents. This is highly debated. IMO, these should go away completely. I'm speaking as a programmer, and I believe copyright is sufficient. * patent trolls. The solution that this article is referring to is actually just another form of patent troll. It's an entity that owns a bunch of patents, does nothing with them itself, and licenses them out. It's doing this for "good" here, but it's still charging a significant amount (kickstarter isn't going to get you access to these). * crappy patents. Far too many obvious ideas are allowed to be patented. This isn't really anything new. You should see how many patents existed for various paper clips. I'm not convinced that adding ridges to an existing paperclip design justified a new patent by a new owner, for example. There's an awful lot of grey area, and I don't have a very good solution for this - it's all just opinion. * bogus patents. Far too many are granted that have pre-existing implementations. On one hand, I think that, if the patent system can't keep up with the filings and do thorough checks, then they should charge more for filing so they can afford to do the checks. On the other hand, patents should be affordable for the average joe, else one of the primary purposes is complete dead. Perhaps it should be significantly easier and cheaper to challenge a patent without involving the owner at all (ie. send in a form, proof/examples of existing work, a check, and have it reviewed). * vague infringement claims. If some entity claims publicly that something/someone is infringing on a bunch of its thousands of patents, it should have to provide evidences and references of some degree. If they don't, it should be handled somewhat like slander. These threats disrupt the market and hurt others without
... but a customer brings a mobile wifi hotspot they are paying for themselves, they should not be blocked in using it. They won't be utilizing the hotel's wifi at all anyway, so why should the hotel with their shitty wifi setup be concerned?
Just playing devils advocate... There are legit reasons they would want to block all those random wifi hotspots. All those random hotspots are (or could) degrade the performance of the service they are offering. The air does not have unlimited bandwidth. If they knock out all the "rogue" hotspots, they *could* manage the airways within their building better.
If they were doing that all for free, it'd be a lot easier to believe that they were doing it in the best interests of their customers and themselves. As such, I tend to agree that they're just doing this for the money.
If I ever owned a large apartment building, and assuming it was new or could be retrofitted easily enough (ie. if there were few to no active tenants at the time), I'd definitely do building-wide "free" internet access ("free" paid for by part of their rent), with multiple gigabit ports in each apartment and well designed wifi throughout. I'd probably include a rider that certain bands/channels are restricted, so users could use their own AP if they want, so long as they don't stomp on what's already there. It'd take a bit of engineering, but it'd be worth it. As it is, whenever I move to a new place, I scan for what's being used and try to pick channels that are unused or underused.
IMO, what the hotel should do is to say they can use specific channels, then only do the bouncing stuff on other channels. That'd still probably be overkill and cause more grief than its worth, but at least it'd be somewhat justifiable.
Ok, so I was completely accurate in my depiction of what you are proposing:
It should be possible to do something similar using the voice layer, but then the #1 is worse, and the call route can easily be move around anywhere, and it'd be packetized voice, encrypted, then turned analog, then going over voice, which goes over a digital network for parts of the transit, and unwraps again on the other side, with nearly all the same drawbacks to the existing system.
What's the point? I'm stretching here, but I can only think of two benefits to sending the packetized and encrypted voice data over the existing voice network: 1. You could still use a POTs line if you plugged in a handset that had the ability to speak that language (ie. you have a buy new handsets or a house-wide filter) 2. On the cell network, it could still work when you lose data (3g/4g/roaming/etc) but happen to still have enough signal for voice.
#1 is, IMO, a silly edge case with very very very few potential users (assuming the competing protocol goes over IP). #2 carries all the same issues previously stated, as well as bandwidth issues (there's going to be overhead to packetizing, encrypting, then encoding into something akin to v.90, and there will be loss and retransmission issues to deal with, so you'd better compress the audio a TON).
The same sort of thing can be done using the IP network and an app, and it'd automatically get a bunch of benefits that are non-existent if you're shoving it down the voice network. Using the IP network with end-to-end encryption with perfect forward secrecy would also solve your other issue of LEO's snagging call records carte-blanche.
If you still wanted to solve #1 and #2 mentioned above, you could use a gateway device. For the home phones, something like this at the premise: http://www.newegg.com/Product/...... or they could dial into a gateway (just like old dial-up modems, which is all it is you are suggesting, just with an encryption layer on top).
As bad as the US has become, I'm glad I'm not from the UK.
This isn't very different from what most US based ISP's do with DNS these days (go to a non-existent page, and they redirect to their own search/helper site). In the DNS case, it's somewhat difficult to disable (finding the URL where you can set it is difficult), and it will occassionally re-enable itself.
I don't really like any of this crap, but it's been done for a long time and it's not *too* awful (once disabled, everything works as it should; more-or-less a one time setting). The way they get that answer is, IMO, wrong. If they need an answer, then use the contacts they have on record (email, phone, mail, etc), set a cut off date, and provide a default. This is a technical solution to a simple and easily solved problem (though, on paper, it may seem like the technical solution costs less, but now you've gotta run that thing indefinitely, and deal with the fallout and bad press and support for it).
[1] Do you have a better technical solution? [2] Does your solution work without requiring the carriers to spend billions radically altering/upgrading their infrastructure [3] Can your proposal somehow conceal which endpoints calls are between? [4] Can your proposal somehow conceal the duration of the call, beyond padding it out for some additional period? [5] Can your solution easily inter-operate on with existing endpoints?
1. Yes. 2. Yes. 3. Limited, but your solution is a no. 4. No. 5. Yes.
The solution you proposed requires the underlying transit layer. In this case, it appears that you are suggesting to use the established voice call to do the further exchange over that. I think that's a little silly since there are better transports available on virtual all phones that your solution is targetting (IE: IP).
If you want your proposed solution, then use an app that does encrypted voip. The IP part can be used to further protect you - you could run it over Tor if you wanted, or to a private vpn, etc etc etc, which is why I didn't put a direct "No" in #3.
It should be possible to do something similar using the voice layer, but then the #1 is worse, and the call route can easily be move around anywhere, and it'd be packetized voice, encrypted, then turned analog, then going over voice, which goes over a digital network for parts of the transit, and unwraps again on the other side, with nearly all the same drawbacks to the existing system.
However, your system really fall flat for the same reason that most of the completely-illiminate-spam solutions fail. See https://craphound.com/spamsolu...
IMO, if we want to eventually have very secure communication channels, we should start with things that are very easy to solve and are in very common use. For example, instant messaging or SMS. Both already require source and destination to be well defined, and both are simple plain text. End to end encryption is really really simple to add on to these, and there are numerous products that can do so. Getting a standard in place, and getting interoperability, and getting widespread adoption have all failed. If we can't get these very simple systems into widespread use, it doesn't bode well for more complicated solutions.
Besides, phone calls have never been secure. If ever one wanted to make a secure call, it was always a given that extra work/parts would need to be involved. I do hope the SS7 issue is somehow fixed, but I don't think it's really going to change much in the grand scheme of things.
At 882 feet, the modern 1100 foot super cruise ship doesn't kill it.
You don't have to read the article but, if you just glance at it, one of the first things you'll see is a rendering of one of their cruise ships next to the titanic. I'd agree with the author, "Compared to a modern cruise ship, however, Titanic was a pipsqueak."
You're not even trying to pretend there is a majority, let alone a small enough group of those that do want a touchscreen to make supporting one viable.
Some of us don't like holding our arm out in mid-air just to move the pointer and to select things.
I know of no desktop nor laptop with a touchscreen that lacks a secondary pointing device. Sure, you could make one that way, but you'd have to do so purposefully. Augment your pointer usage with a touchscreen and it can be very useful, especially on a laptop.
On a laptop sans-touchscreen, there are many times I just want to jab at the screen to hit some button or notification, rather than have to move my mouse around to get to it (via crappy touchpad or nub). Even if you have a mouse attached, a quick jab to the screen right where the button is will be faster than moving your hand to the mouse and moving it around and clicking and them coming back to the keyboard. It's perfectly workable to live without a touchscreen, but let's not pretend that it's a negative.
AFAICT, marks on the screen are the only real downside to adding a touchscreen. I don't eat cheetos while typing, so it's not much of a problem for me, and certainly nothing that a quick wipe down won't cure/mitigate.
That said, it'd be useless on my desktop because, as you noted, it's too far away. Dual 30" monitors aren't really the norm either though. On a tablet or phone, I think we're all fine with the touchscreen (though I still prefer a hardware keyboard.... wish more phone models had them).
I wonder about the value of capturing power during off peak hours and providing it back during peak hours.
Hot damn that sounds like a great idea! While I'm confident it wouldn't be profitable due to combo of price of batteries + efficiency of them (ie. loss) + difference between day/night rates won't be enough to cover the loss and up front cost, it's still a fun thought.
Your load avg would look crazy, especially if you had solar during the day feeding excess back to the grid - massive negative usage during the day, massive usage at night... ramp it up as high as you can.
If it were profitable, the gigafactory itself could do that.
What's the math to be applied to LBAs? How big is an LBA? A 512 byte sector?
My nearly 4 year old Samsung shows just under 2 TB written if I multiply the SMART-provided Total LBAs written against a 512 byte block.
Correct. Though there could be differences depending on the model of drive you have, it's very likely 512B LBAs: http://www.samsung.com/global/...
Since you said you have a samsung, you can run the Samsung Magician 4.0 and it'll do the conversions for you (assuming you're running Windows or Mac; AFAIK, Magician isn't available for Linux).
Let's do some math here, shall we? At 200 MB/s, you can overwrite a 1 TB drive in an hour. 1 PB you can reach in a month. The hard drives are a few times larger than the SSDs, so you'd need ~ 10 TB instead of 2, which means 10 months.
Include all the actual variables, and you might get a usable answer. Just blowing data on the disk isn't the only thing this is doing (AFAIK). You've gotta detect errors, so you've gotta read back the data and validate it. This page goes through their full testing methodology (hint: they're using Anvil, a static file collection that includes a copy of a windows install, some applications, some movies, and some incompressible data, among other things, and every file has its md5sum checked after writing): http://techreport.com/review/2...
An easier calculation would be to scale their timelines to the HDD stats. For example: Samsung 840 Pro sequential read/write: 540MB/s / 520MB/s (390MB/s for 128GB) WD Caviar Black: about 180MB/s read/write (ex. http://www.storagereview.com/w...) Rough math: 520 / 180 = 2.89 = it'll take 2.89 times as long to do the test on the same size drive.
Samsung 840 Pro size in the article: 256GB Assuming you use WD Caviar Black 1TB = 4x's the size. 2.89 * 4 = 11.55 = that many times as long to do the same operations they've done thus far.
Their test has been running for over a year. So it'd take (roughly) over 11.5 years to do the same on the WD Caviar Black. I understand that's a very very rough estimate, but I think it's MUCH closer to the ballpark than 10 months!
My bet: the WD will be dead long before that time. I've had drives last longer than that, but they got VERY VERY little use and were simply powered on all the time. I've had some that lasted longer than that and got a fair bit of use (ex. db servers), but they were never filled to capacity, they were enterprise drives, and some of their neighbors did die (RAID).
If they'd used a 32 bit unsigned integer they might have bought another 6 months or something.
You could say the same of the unix time_t problem, which is a signed 32bit int. If it were unsigned, it'd go to 2106 instead of 2038. Either way, that's not not really the solution. The solution, as youtube has done, is to move to 64bit int.
Personally, I'm amazed at the hit count! There are 2^31 seconds between 1970-01-01 and 2038-01-19. If this video was watched once every second since 1970, it'd still have 24 years before it rolled over that counter. By comparison, it hasn't been available very long. How many views a second is that thing getting? On average, more than 28 hits a second!!!
28 hits/sec may not seem outrageous for a very popular file on a very popular site, but that's averaged since July 2012 until today. That, IMO, is nuts.
There are certainly costs associated with ruggedizing things; but those ruggedization costs apply to any laptop(so if it's more expensive than a chromebook now the ruggedized version is going to be more expensive than the ruggedized chromebook);
The ruggedizing is, essentially, a flat cost. As such, the price increase as viewed in relation to the cost of the original device would be much greater on a chromebook. Eg. $200 chromebook + $200 to ruggedize it = 2x's the base cost, or 100% more $900 laptop + $200 to ruggedize it = 1.22x's the base cost, or 22% more
When you're getting a bunch of them, that significantly changes the number of them you can get. $20,000 = 100x $200 chromebooks... or = 50 ruggedized $400 chromebooks $90,000 = 100x $900 laptops... or = 82 ruggedized $1100 laptops
This is the key point I think the others we making. You'll still get broken ruggedized ones, but fewer of them. How many need to break of the cheap model before it is worth getting the ruggedized ones? With chromebooks being so cheap, there would have to be a phenomenal number of broken ones before you'd break even.
Car analogy... it'd be like getting full coverage insurance on a used 1986 honda civic that you own outright. It'd be cheaper to pay for a new one with cash than deal with the deductible + high rate when they total it!
To quote sribe, "It would only be circular if in turn the higher reserves led to higher expenses"
The theory that is being suggested is one of linear growth, not circular. As they grow (or as time moves forward), they continue to spend more on stuff (staff, operations, management, etc). This has an effect on anything tied to revenue: larger investments should be returning proportionally larger returns; taxes, if any, will increase proportionately; and, yes, if they want 1 year worth of reserve cash, that value will increase proportionately to spending.
That is not circular. Perhaps if someone proposed a theory the higher reserves are encouraging higher spending and had any backing for said statement, then maybe there'd be a circular condition, but that is not what was stated.
Please correct me if I'm wrong (I've read loads of docs on Docker, but have not used it yet). From what I've read, the problem you describe is not a technical limitation/implementation detail of Docker, but is simply a symptom of how it is generally being used.
Only, the implementation brings with it the same flawed approach as Solaris Zones. Do we really need a full OS image running in a container?...
I think what Rocket really represents is a way to do containers right. Containers should run a single process. We shouldn't look at containers as a more efficient VM. We should see containers as a way to increase security and reduce overhead....
From what I've read, a Docker container can have as few things in it as you want (or as much as you want, up to the everything but the kernel). If you were doing an Apache container, you might put apache, mod_ssl, the ssl libs, mod_php, perl, libperl, mod_perl, etc in there, but you don't have to put glibc or other libs in there. It'll use the hosts libs and apps as needed/configured. As far as I can tell, you don't even have to put all that in there... you could leave the openssl, libperl, etc outside on the host and configure the container to use the hosts stuff for those. Again, please correct me if I'm mistaken.
I get the feeling that many are embracing Docker as a way to distribute containers for certain tasks. As such, they include everything the services within the container needs so that it will run on any host with Docker support, which makes them easier to distribute (somewhat like VMware's Virtual Appliance exchange). The fact that it can function this was does not mean (AFAICT) that it must function this way.
Docker containers can also stack, where one container may just be a diff on top of one (or more?) other containers. There's a whole lot of flexibility. That flexibility does make it somewhat difficult to approach, and I think the result is what we're seeing - containers being distributed that tend to look a lot more like virtual appliances withe a nearly complete OS stack included. AFAIK, that's not the only way to do it, it's just the best fit when you're offering a container for anyone to download and use.
Personally, I'd like to see some examples where a normal OS install is altered to use containers in all the places that chroot's are currently used, and do so with similarly light handed approaches. For example, see default bind installs where chroot is often done by default with the distro. I imagine it would be quite trivial to stick bind in a Docker/LXC/Rocket container with almost no OS parts included. I think this is the sort of solution you were referring to as "do containers right". Can this not be done with Docker today? If not, why not?
What I don't get are these two comments directly from the first article linked:
1. "Not only do you not have to sign up for a service, but you also don’t need the same software or hardware as the person you want to call, since WebRTC is compatible with Chrome and Opera browsers as well."
2. "... by sharing the generated callback link. To call you, they’ll naturally need Firefox 34."
So which is it? Something's wrong there.
As others have said, this should be an add-on. That said, I doubt it introduces much of any bloat when you're not using it (at least I really really hope it doesn't do anything at all unless you use it).
This thread is surprisingly short, and mostly has people either agreeing that fast breeders or something similar are a great solution (maybe with some bickering on the finer points), or off topic arguing about the total investments made in various tech. FWIW, I'm 100% on board with reprocessing. I can only guess that either: a) most people are also fine with this, so no need to post to agree... let's just post in places where we can argue b) the proliferation risks make the conversation untouchable to them
This seems to happen on every nuclear thread on slashdot. I really really really don't understand why the US doesn't just set up one plant to reprocess waste. I'm very much against burying all the existing waste anywhere (Yuka, shale, or any other hole). As it is, it simply has too long of a life for me to accept that it'll be fine - we're really bad at thinking on such scales. If it were reprocessed first into something with a MUCH MUCH shorter half life, then I'd be fine burying that stuff - I think we might be able to handle managing a big dump of stuff for 1-2 hundred years, though that's still a stretch.
The point I'm getting at is, if we had a fast breeder reprocessing all our nuclear waste, I think many of the other concerns about waste would just about disappear. The topic would change to protecting the much smaller amount of weapons grade waste. Since it's small and in one place, I think that's not only feasible, but much easier than dealing with protection and maintenance of more than a hundred piles of nasty waste spread all around the country. I'm not a nuclear engineer, but it seems like a no brainer to me, and the only argument I've heard against it is the nuclear proliferation laws and concerns regarding plutonium. To those, I saw WTF - that's very minor red tape in comparison to things like the Yuka Mt debate.
Slashdot Mirror
How about dumb users that suffer from 0-day exploits in their up-to-date OS ? I doubt they'll be happy if they are kicked off the internet for something they can do nothing about, and can only get back online after they've waited for a bugfix and reinstalled their entire machine.
Talk about out of context!
I proposed two solution that could take out botnets that do NOT rely on either:
* completely eliminating both security flaws
* dumb users that install malicious software because some web popup told them to.
0-day exploits falls into the former. Yes, they'd get destroyed, alterered, or kicked off by their ISP in the proposed solutions. Tough luck, but if your computer is part of a botnet, it deserves to be kicked off (at the very least). Fix it and then ask to have your service re-established.
FWIW, ISP's already do this to protect the MPAA/RIAA and even have a 3 strikes rule where you'll never get back on, and there's even a chance you'll get sued in that case. Everything is in place to be able to do this though, as I noted, ISP's are unlikely to do it as it'll cost them money and customers.
You can only kill the malware that is behind these DDoS's by completely eliminating security flaws in software. ...
Wrong.
There's multiple times of DDoS's. Let's get that out of the way.... we're talking about botnet based DDoS here. Solutions are different for other types.
Given a botnet attacking one or more targeted hosts, it's relatively easy to identify a large number of the hosts involved in the attack.
While illegal, once you have that, it's quite feasible infiltrate at least a subset of those hosts. Go from there and infiltrate the botnet as a whole (determine command and control stuff, determine other bots, take over for a short period of time). While you own it, kill all the hosts (something between full wipe of the HDD, just disabling their ability to get online, and doing a surgical removal of any malware and securing the system... I'd lean towards the middle of those).
If one entity did such a thing, they'd be labeled as an awful and horrible hacker by many, so it's not going to happen.
A legal, but much slower way with loads more red tape, would be to involve the users ISP's. Give them the lists of hosts, and have them ID the owners then immediately terminate their service. That's going to cost the ISP money to do it, and it's a loss of revenue losing those customers, so this isn't going to happen unless our laws change to require this.
Both those are technically possible though, unlike completely eliminating both security flaws and dumb users that install malicious software because some web popup told them to.
Just because the airlines claim to be broke doesn't mean they are. Football teams in the USA also claim they lose money all the time.
THIS!
If you run a business and show loads of profit, you'll pay loads of taxes on said profit. In addition, especially in this case, users would be pissed and complaining that they were being overcharged.
Work the books so that you have a tight margin, and even run in the red a couple years at a time (at least), and you'll be better off as a company. In this case, they can also milk extra money from the government since we couldn't do without airlines.
All that said, it is an industry that is extremely expensive to maintain. Lots of room for failure, and even more room to lose money within the company (whether on purpose or not).
Anyone know someone that owns a small plane? The gas cost for a short-ish flight, split between the 2-4 passengers, can run more than a seat on a normal airline. That's not even counting the cost of the plain, maintenance, hanger fees, etc etc etc. It's pretty amazing we can fly for the prices we have now.
Zediva was shutdown because like Aero they tried to work around the laws to skip paying for a license from the content provider.
They were purchasing regular DVDs and renting them in violation of the DVD license. Rental DVDs require a totally different license.
[bolded by me] That part is not true AFAICT. See The Consumer Video Sales/Rental Amendment of 1983.
In that case, the doctrine of first sale was upheld, and you can do whatever you want with something that you have legitimately acquired a copy of (ex. VHS or DVD).
Just one of many examples:
http://thinkprogress.org/ygles...
The paranoid are using one-time-pads...
Thank you for this but:
a) if they're using that for real time chat, that's not the complete solution. How does it all tie together?
b) if they're not using it for real time chat, then that doesn't answer the question really.
Even for simple status updates and such, "OTP on a microSD" is still not a complete answer. If I had my OTP stored anywhere, then it'd also be encrypted. Then there's the matter of how to decrypt the OTP wherever one happens to be. All very solvable, but a detailed doc of all the parts and how they fit together and what tools are used with them etc etc would be nice to see.
The details are what I was hoping to see. As it is, the article(s) seem pretty useless (though they had that potential).
It will be as successful as the "legalize marijuana" petition.
Is that really the example you want to use? Is the answer, "fairly successful"?
23 states and District of Columbia currently have laws legalizing marijuana in some form.
4 states have legalized it for recreational use (6 in 2015).
Many states have eliminated or greatly reduced penalties for small amounts of it.
Population-wise, and electoral-college-wise, I believe we are well past 50%.
mod parent up.
Rulings like those in Aareo and Zediva's cases almost make it seem like normal DVD rentals and TiVO's will be the next on the chopping block. Of course, they tried, but somehow (luckily) those won.
Why the hell Zediva got shut down is beyond me.
Aereo was actually more likely to be shut down than Zediva (it could be argued that Aereo put some load on the existing system to sell a rebroadcast to users that were not possible customers of said broadcasts which, while technically should have skirted the laws, was a fairly obvious attempt at getting something for nothing and charging for it while playing tricks to avoid the law). I still thought it was a good service, but it was obviously a kludge.
Ideally, at least in my view, the content owners, or those they've licensed to, would make all their content available at a reasonable rate over the internet. The aggregation and post processing should, IMO, happen at the customer premise. Just like TiVO, but pull the streams from various sources rather than requiring cable TV, satellite TV, Hulu, Netflix, Amazon, Vudu, etc etc etc. In addition, metadata should be free (ie. tv guide data) from anyone broadcasting anything over anything - I mean, why the hell not?
My prediction is that things will continue on what is now the obvious path. Re: see iTunes and mp3's. Essentially, some balance/semi-standard will be set for cost-per-show and cost-per-movie, and a handful of big companies will get access to nearly the entire library, and people will cut back on pirating and kludges such as aereo will no longer be profitable. And yes, dvd sales will drop as quickly as cd sales, and cable tv subscriptions will slowly decline, but that's all just the transport medium. Cut down on cable TV subscriptions, and cable may be able to be more competitive with FiOS for internet access :-)
There's a whole lot of comments here saying this is stupid, obvious, not surprising, etc, and pointing out other clients that have used (and still use) XMPP (jabber).
The one potentially interesting bit that brought me here... what are they using for encryption?
I'm assuming they have TLS enabled from client to server, and from server to server. The details for that layer are not very important to me, though I'd still be interested to know.
The end-to-end encryption used, that's what I'd be most curious to hear about. There's a lot of apps and plugins and such that boast end-to-end encryption, but there is little interoperability AFAICT. There's a fairly wide variety of implementations and specs (and lack thereof). OTR may be the best known one (http://en.wikipedia.org/wiki/Off-the-Record_Messaging). IMO, what it uses seems somewhat dated with respect to all the SSL/TLS issues that came to light this past year. Ex, OTR uses:
* Diffie-Hellman key exchange with 1536 bit group size. (is this ADH, static DH, DHE, ECDH, ECDHE, etc)
* AES symmetric key with 128 bit key length (AES 256 is more the norm now, and there are certainly lots of other alternatives)
* SHA-1 hash function (SHA1 is deprecated in many situations, and SHA256 and other stronger hash functions are readily available)
* forward secrecy (that's good... but I wonder if it's using similar and well tested methods such as used in current PFS TLS implementations)
* NO support for multi-user group chat
I'm betting there's better and/or more updated things out there. Seems OTR could be updated fairly easily (define new protocol version and use different set of stuff in the various places in the protocol), but what is it that others that are extremely paranoid are using?
Dude, with 2800 chairs per person, I could build every man woman and child a chairhouse, guest chairhouse, summer chairhouse and chairhouse cabin.
Build log cabin-ish structures, rather than drywall covered toothpicks that are so common today. I'm betting that'd get is a lot closer to being effective, but it's still a pretty stupid/naive idea.
We've destroyed a ton of rain forest. No amount of planting trees in our backyards is going to make up for that, especially when most backyards used to have trees, or already do. To tackle the problem with vegetation, we'd need to reverse the rain forest deforestation, cultivate arid lands (deserts and dustbowls), and probably look into ocean based stuff (algae etc... oceans covering more of the earth than anything else, have they all have water and sunlight readily available).
Personally, I'm a bit curious (but not curious enough to look it up) how long it'll take, or how rich in CO2 we'd need to be, before we see giant pre-historic-ish trees make a comeback. I'm guessing we'll all be dead before that happens, but I like to think the earth will manage just fine with huge CO2 levels, even flourish.
That's a really good idea, but... cue inane "coprorations are people" counter-argument.
It's a crap idea. If patents could not be transferred, then if person X worked for company Y, and then went to company Z, they'd be taking the patents with them with no means to leave them with the company that was using them.
Furthermore, it doesn't solve anything... company X can buy company Y and then give themselves free licensing rights and have their legal team take over suing others just as companies do now. If you're thinking, "you wouldn't be allowed to only buy the patents", that's trivial to work around... sell off all the other parts of the business, leaving only the patents, then sell everything that's left (just the patents).
Regardless, one could still assign full rights to manage said patent portfolio to some 3rd party company. That would be nearly impossible to avoid - just consider the 3rd party as a bunch of lawyers and have them do all the same stuff those 3rd parties are doing today, simply leaving the actual patent assignment where it was.
How about we modify that solution a little... (NOTE: this is a proposal, not a statement of the current situation)
#1. corporations are not people (not sure which way you meant that counter-argument to read).
#2. corporations can not hold patents
#3. people can transfer patents to other people, or sell licensing agreements with terms of their choosing
FWIW, I do not claim that would solve the problem either. I think that's better than the current situation, but it's still fairly easy to manipulate and end up in a functionally identical situation. Someone patents something while working for a company; company draws up paperwork to have a zero cost licensing agreement with that employee (or maybe gives them a bonus or something... up to them); company and employee could agree to sign over the rights to some other person at the company; company would essentially own the patent. There'd be more ways to get a patent out of the loop, but with the right paperwork in place it wouldn't matter.
There are a bunch of real problems with the current system, but the ownership thing is really more of a symptom of those issues than an actual problem.
* software patents. This is highly debated. IMO, these should go away completely. I'm speaking as a programmer, and I believe copyright is sufficient.
* patent trolls. The solution that this article is referring to is actually just another form of patent troll. It's an entity that owns a bunch of patents, does nothing with them itself, and licenses them out. It's doing this for "good" here, but it's still charging a significant amount (kickstarter isn't going to get you access to these).
* crappy patents. Far too many obvious ideas are allowed to be patented. This isn't really anything new. You should see how many patents existed for various paper clips. I'm not convinced that adding ridges to an existing paperclip design justified a new patent by a new owner, for example. There's an awful lot of grey area, and I don't have a very good solution for this - it's all just opinion.
* bogus patents. Far too many are granted that have pre-existing implementations. On one hand, I think that, if the patent system can't keep up with the filings and do thorough checks, then they should charge more for filing so they can afford to do the checks. On the other hand, patents should be affordable for the average joe, else one of the primary purposes is complete dead. Perhaps it should be significantly easier and cheaper to challenge a patent without involving the owner at all (ie. send in a form, proof/examples of existing work, a check, and have it reviewed).
* vague infringement claims. If some entity claims publicly that something/someone is infringing on a bunch of its thousands of patents, it should have to provide evidences and references of some degree. If they don't, it should be handled somewhat like slander. These threats disrupt the market and hurt others without
... but a customer brings a mobile wifi hotspot they are paying for themselves, they should not be blocked in using it. They won't be utilizing the hotel's wifi at all anyway, so why should the hotel with their shitty wifi setup be concerned?
Just playing devils advocate...
There are legit reasons they would want to block all those random wifi hotspots. All those random hotspots are (or could) degrade the performance of the service they are offering. The air does not have unlimited bandwidth. If they knock out all the "rogue" hotspots, they *could* manage the airways within their building better.
If they were doing that all for free, it'd be a lot easier to believe that they were doing it in the best interests of their customers and themselves. As such, I tend to agree that they're just doing this for the money.
If I ever owned a large apartment building, and assuming it was new or could be retrofitted easily enough (ie. if there were few to no active tenants at the time), I'd definitely do building-wide "free" internet access ("free" paid for by part of their rent), with multiple gigabit ports in each apartment and well designed wifi throughout. I'd probably include a rider that certain bands/channels are restricted, so users could use their own AP if they want, so long as they don't stomp on what's already there. It'd take a bit of engineering, but it'd be worth it. As it is, whenever I move to a new place, I scan for what's being used and try to pick channels that are unused or underused.
IMO, what the hotel should do is to say they can use specific channels, then only do the bouncing stuff on other channels. That'd still probably be overkill and cause more grief than its worth, but at least it'd be somewhat justifiable.
Ok, so I was completely accurate in my depiction of what you are proposing:
It should be possible to do something similar using the voice layer, but then the #1 is worse, and the call route can easily be move around anywhere, and it'd be packetized voice, encrypted, then turned analog, then going over voice, which goes over a digital network for parts of the transit, and unwraps again on the other side, with nearly all the same drawbacks to the existing system.
What's the point? I'm stretching here, but I can only think of two benefits to sending the packetized and encrypted voice data over the existing voice network:
1. You could still use a POTs line if you plugged in a handset that had the ability to speak that language (ie. you have a buy new handsets or a house-wide filter)
2. On the cell network, it could still work when you lose data (3g/4g/roaming/etc) but happen to still have enough signal for voice.
#1 is, IMO, a silly edge case with very very very few potential users (assuming the competing protocol goes over IP).
#2 carries all the same issues previously stated, as well as bandwidth issues (there's going to be overhead to packetizing, encrypting, then encoding into something akin to v.90, and there will be loss and retransmission issues to deal with, so you'd better compress the audio a TON).
The same sort of thing can be done using the IP network and an app, and it'd automatically get a bunch of benefits that are non-existent if you're shoving it down the voice network. Using the IP network with end-to-end encryption with perfect forward secrecy would also solve your other issue of LEO's snagging call records carte-blanche.
If you still wanted to solve #1 and #2 mentioned above, you could use a gateway device. ... or they could dial into a gateway (just like old dial-up modems, which is all it is you are suggesting, just with an encryption layer on top).
For the home phones, something like this at the premise: http://www.newegg.com/Product/...
As bad as the US has become, I'm glad I'm not from the UK.
This isn't very different from what most US based ISP's do with DNS these days (go to a non-existent page, and they redirect to their own search/helper site). In the DNS case, it's somewhat difficult to disable (finding the URL where you can set it is difficult), and it will occassionally re-enable itself.
I don't really like any of this crap, but it's been done for a long time and it's not *too* awful (once disabled, everything works as it should; more-or-less a one time setting). The way they get that answer is, IMO, wrong. If they need an answer, then use the contacts they have on record (email, phone, mail, etc), set a cut off date, and provide a default. This is a technical solution to a simple and easily solved problem (though, on paper, it may seem like the technical solution costs less, but now you've gotta run that thing indefinitely, and deal with the fallout and bad press and support for it).
[1] Do you have a better technical solution?
[2] Does your solution work without requiring the carriers to spend billions radically altering/upgrading their infrastructure
[3] Can your proposal somehow conceal which endpoints calls are between?
[4] Can your proposal somehow conceal the duration of the call, beyond padding it out for some additional period?
[5] Can your solution easily inter-operate on with existing endpoints?
1. Yes.
2. Yes.
3. Limited, but your solution is a no.
4. No.
5. Yes.
The solution you proposed requires the underlying transit layer. In this case, it appears that you are suggesting to use the established voice call to do the further exchange over that. I think that's a little silly since there are better transports available on virtual all phones that your solution is targetting (IE: IP).
If you want your proposed solution, then use an app that does encrypted voip. The IP part can be used to further protect you - you could run it over Tor if you wanted, or to a private vpn, etc etc etc, which is why I didn't put a direct "No" in #3.
It should be possible to do something similar using the voice layer, but then the #1 is worse, and the call route can easily be move around anywhere, and it'd be packetized voice, encrypted, then turned analog, then going over voice, which goes over a digital network for parts of the transit, and unwraps again on the other side, with nearly all the same drawbacks to the existing system.
However, your system really fall flat for the same reason that most of the completely-illiminate-spam solutions fail. See https://craphound.com/spamsolu...
IMO, if we want to eventually have very secure communication channels, we should start with things that are very easy to solve and are in very common use. For example, instant messaging or SMS. Both already require source and destination to be well defined, and both are simple plain text. End to end encryption is really really simple to add on to these, and there are numerous products that can do so. Getting a standard in place, and getting interoperability, and getting widespread adoption have all failed. If we can't get these very simple systems into widespread use, it doesn't bode well for more complicated solutions.
Besides, phone calls have never been secure. If ever one wanted to make a secure call, it was always a given that extra work/parts would need to be involved. I do hope the SS7 issue is somehow fixed, but I don't think it's really going to change much in the grand scheme of things.
At 882 feet, the modern 1100 foot super cruise ship doesn't kill it.
You don't have to read the article but, if you just glance at it, one of the first things you'll see is a rendering of one of their cruise ships next to the titanic. I'd agree with the author, "Compared to a modern cruise ship, however, Titanic was a pipsqueak."
Laptops with touchscreens make perfect sense.
Some of us... Some of us... Some of us...
You're not even trying to pretend there is a majority, let alone a small enough group of those that do want a touchscreen to make supporting one viable.
Some of us don't like holding our arm out in mid-air just to move the pointer and to select things.
I know of no desktop nor laptop with a touchscreen that lacks a secondary pointing device. Sure, you could make one that way, but you'd have to do so purposefully. Augment your pointer usage with a touchscreen and it can be very useful, especially on a laptop.
On a laptop sans-touchscreen, there are many times I just want to jab at the screen to hit some button or notification, rather than have to move my mouse around to get to it (via crappy touchpad or nub). Even if you have a mouse attached, a quick jab to the screen right where the button is will be faster than moving your hand to the mouse and moving it around and clicking and them coming back to the keyboard. It's perfectly workable to live without a touchscreen, but let's not pretend that it's a negative.
AFAICT, marks on the screen are the only real downside to adding a touchscreen. I don't eat cheetos while typing, so it's not much of a problem for me, and certainly nothing that a quick wipe down won't cure/mitigate.
That said, it'd be useless on my desktop because, as you noted, it's too far away. Dual 30" monitors aren't really the norm either though.
On a tablet or phone, I think we're all fine with the touchscreen (though I still prefer a hardware keyboard.... wish more phone models had them).
I wonder about the value of capturing power during off peak hours and providing it back during peak hours.
Hot damn that sounds like a great idea!
While I'm confident it wouldn't be profitable due to combo of price of batteries + efficiency of them (ie. loss) + difference between day/night rates won't be enough to cover the loss and up front cost, it's still a fun thought.
Your load avg would look crazy, especially if you had solar during the day feeding excess back to the grid - massive negative usage during the day, massive usage at night... ramp it up as high as you can.
If it were profitable, the gigafactory itself could do that.
What's the math to be applied to LBAs? How big is an LBA? A 512 byte sector?
My nearly 4 year old Samsung shows just under 2 TB written if I multiply the SMART-provided Total LBAs written against a 512 byte block.
Correct.
Though there could be differences depending on the model of drive you have, it's very likely 512B LBAs:
http://www.samsung.com/global/...
Since you said you have a samsung, you can run the Samsung Magician 4.0 and it'll do the conversions for you (assuming you're running Windows or Mac; AFAIK, Magician isn't available for Linux).
Let's do some math here, shall we? At 200 MB/s, you can overwrite a 1 TB drive in an hour. 1 PB you can reach in a month. The hard drives are a few times larger than the SSDs, so you'd need ~ 10 TB instead of 2, which means 10 months.
Include all the actual variables, and you might get a usable answer. Just blowing data on the disk isn't the only thing this is doing (AFAIK). You've gotta detect errors, so you've gotta read back the data and validate it. This page goes through their full testing methodology (hint: they're using Anvil, a static file collection that includes a copy of a windows install, some applications, some movies, and some incompressible data, among other things, and every file has its md5sum checked after writing): http://techreport.com/review/2...
An easier calculation would be to scale their timelines to the HDD stats. For example:
Samsung 840 Pro sequential read/write: 540MB/s / 520MB/s (390MB/s for 128GB)
WD Caviar Black: about 180MB/s read/write (ex. http://www.storagereview.com/w...)
Rough math: 520 / 180 = 2.89 = it'll take 2.89 times as long to do the test on the same size drive.
Samsung 840 Pro size in the article: 256GB
Assuming you use WD Caviar Black 1TB = 4x's the size.
2.89 * 4 = 11.55 = that many times as long to do the same operations they've done thus far.
Their test has been running for over a year. So it'd take (roughly) over 11.5 years to do the same on the WD Caviar Black. I understand that's a very very rough estimate, but I think it's MUCH closer to the ballpark than 10 months!
My bet: the WD will be dead long before that time. I've had drives last longer than that, but they got VERY VERY little use and were simply powered on all the time. I've had some that lasted longer than that and got a fair bit of use (ex. db servers), but they were never filled to capacity, they were enterprise drives, and some of their neighbors did die (RAID).
If they'd used a 32 bit unsigned integer they might have bought another 6 months or something.
You could say the same of the unix time_t problem, which is a signed 32bit int. If it were unsigned, it'd go to 2106 instead of 2038. Either way, that's not not really the solution. The solution, as youtube has done, is to move to 64bit int.
Personally, I'm amazed at the hit count!
There are 2^31 seconds between 1970-01-01 and 2038-01-19.
If this video was watched once every second since 1970, it'd still have 24 years before it rolled over that counter.
By comparison, it hasn't been available very long. How many views a second is that thing getting? On average, more than 28 hits a second!!!
28 hits/sec may not seem outrageous for a very popular file on a very popular site, but that's averaged since July 2012 until today. That, IMO, is nuts.
There are certainly costs associated with ruggedizing things; but those ruggedization costs apply to any laptop(so if it's more expensive than a chromebook now the ruggedized version is going to be more expensive than the ruggedized chromebook);
The ruggedizing is, essentially, a flat cost. As such, the price increase as viewed in relation to the cost of the original device would be much greater on a chromebook. Eg.
$200 chromebook + $200 to ruggedize it = 2x's the base cost, or 100% more
$900 laptop + $200 to ruggedize it = 1.22x's the base cost, or 22% more
When you're getting a bunch of them, that significantly changes the number of them you can get. ... or = 50 ruggedized $400 chromebooks ... or = 82 ruggedized $1100 laptops
$20,000 = 100x $200 chromebooks
$90,000 = 100x $900 laptops
This is the key point I think the others we making. You'll still get broken ruggedized ones, but fewer of them. How many need to break of the cheap model before it is worth getting the ruggedized ones? With chromebooks being so cheap, there would have to be a phenomenal number of broken ones before you'd break even.
Car analogy... it'd be like getting full coverage insurance on a used 1986 honda civic that you own outright. It'd be cheaper to pay for a new one with cash than deal with the deductible + high rate when they total it!
To quote sribe, "It would only be circular if in turn the higher reserves led to higher expenses"
The theory that is being suggested is one of linear growth, not circular. As they grow (or as time moves forward), they continue to spend more on stuff (staff, operations, management, etc). This has an effect on anything tied to revenue: larger investments should be returning proportionally larger returns; taxes, if any, will increase proportionately; and, yes, if they want 1 year worth of reserve cash, that value will increase proportionately to spending.
That is not circular. Perhaps if someone proposed a theory the higher reserves are encouraging higher spending and had any backing for said statement, then maybe there'd be a circular condition, but that is not what was stated.
Please correct me if I'm wrong (I've read loads of docs on Docker, but have not used it yet).
From what I've read, the problem you describe is not a technical limitation/implementation detail of Docker, but is simply a symptom of how it is generally being used.
Only, the implementation brings with it the same flawed approach as Solaris Zones. Do we really need a full OS image running in a container? ...
I think what Rocket really represents is a way to do containers right. Containers should run a single process. We shouldn't look at containers as a more efficient VM. We should see containers as a way to increase security and reduce overhead. ...
From what I've read, a Docker container can have as few things in it as you want (or as much as you want, up to the everything but the kernel). If you were doing an Apache container, you might put apache, mod_ssl, the ssl libs, mod_php, perl, libperl, mod_perl, etc in there, but you don't have to put glibc or other libs in there. It'll use the hosts libs and apps as needed/configured. As far as I can tell, you don't even have to put all that in there... you could leave the openssl, libperl, etc outside on the host and configure the container to use the hosts stuff for those. Again, please correct me if I'm mistaken.
I get the feeling that many are embracing Docker as a way to distribute containers for certain tasks. As such, they include everything the services within the container needs so that it will run on any host with Docker support, which makes them easier to distribute (somewhat like VMware's Virtual Appliance exchange). The fact that it can function this was does not mean (AFAICT) that it must function this way.
Docker containers can also stack, where one container may just be a diff on top of one (or more?) other containers. There's a whole lot of flexibility. That flexibility does make it somewhat difficult to approach, and I think the result is what we're seeing - containers being distributed that tend to look a lot more like virtual appliances withe a nearly complete OS stack included. AFAIK, that's not the only way to do it, it's just the best fit when you're offering a container for anyone to download and use.
Personally, I'd like to see some examples where a normal OS install is altered to use containers in all the places that chroot's are currently used, and do so with similarly light handed approaches. For example, see default bind installs where chroot is often done by default with the distro. I imagine it would be quite trivial to stick bind in a Docker/LXC/Rocket container with almost no OS parts included. I think this is the sort of solution you were referring to as "do containers right". Can this not be done with Docker today? If not, why not?
What I don't get are these two comments directly from the first article linked:
1. "Not only do you not have to sign up for a service, but you also don’t need the same software or hardware as the person you want to call, since WebRTC is compatible with Chrome and Opera browsers as well."
2. "... by sharing the generated callback link. To call you, they’ll naturally need Firefox 34."
So which is it? Something's wrong there.
As others have said, this should be an add-on. That said, I doubt it introduces much of any bloat when you're not using it (at least I really really hope it doesn't do anything at all unless you use it).
This thread is surprisingly short, and mostly has people either agreeing that fast breeders or something similar are a great solution (maybe with some bickering on the finer points), or off topic arguing about the total investments made in various tech. FWIW, I'm 100% on board with reprocessing. I can only guess that either:
a) most people are also fine with this, so no need to post to agree... let's just post in places where we can argue
b) the proliferation risks make the conversation untouchable to them
This seems to happen on every nuclear thread on slashdot. I really really really don't understand why the US doesn't just set up one plant to reprocess waste. I'm very much against burying all the existing waste anywhere (Yuka, shale, or any other hole). As it is, it simply has too long of a life for me to accept that it'll be fine - we're really bad at thinking on such scales. If it were reprocessed first into something with a MUCH MUCH shorter half life, then I'd be fine burying that stuff - I think we might be able to handle managing a big dump of stuff for 1-2 hundred years, though that's still a stretch.
The point I'm getting at is, if we had a fast breeder reprocessing all our nuclear waste, I think many of the other concerns about waste would just about disappear. The topic would change to protecting the much smaller amount of weapons grade waste. Since it's small and in one place, I think that's not only feasible, but much easier than dealing with protection and maintenance of more than a hundred piles of nasty waste spread all around the country. I'm not a nuclear engineer, but it seems like a no brainer to me, and the only argument I've heard against it is the nuclear proliferation laws and concerns regarding plutonium. To those, I saw WTF - that's very minor red tape in comparison to things like the Yuka Mt debate.