Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment Re:This is why (Score 1) 224

This is why we can't have nice things.

This is why Marketing shouldn't promise things that they can't deliver. They should know that "unlimited" has a specific meaning and if they don't mean it, they shouldn't promise it.

If they promised storing an unlimited number of photographs, it doesn't mean they need to promise that each photograph can be of unlimited size. The number of people who have 1 GB bona-fide photos is vanishingly small, and Amazon is of no obligation to serve them.
However, the next step from "abusers" would be, of course, to store huge files as many separate photos on Amazon.
But I'm not sure why "unlimited" is the point here. If they did limit it to 15 GB (like Google drive's free storage), the abusers could still save 15 GB of non-photo files on this service. This would be less of an abuse?

Comment Re:Old Habits Die Hard (Score 1) 442

What? So if my business is, say, making people unable to turn their TVs on, the people in the TV industry should just "adapt" to people being unable to use their product?

If people want this TV-disabling product, then yes, the TV industry should adapt, perhaps by switching to make a different product, or a new kind of TV that people don't want to disable because they actually like it.

Carpet-bombing of ads - sticking them in every TV show you watch, on every website you visit, every newspaper you read and every road you drive on - are not a force of nature. The ad industry can also pick other solutions. One example is inventing ads that people actually *want*, and even collect (remember coupons?). Another example is only advertise when you really are looking for something - like Google's search ads.

Comment Re:How about slashdot fix the headline.. (Score 4, Informative) 91

IThey are not DROPPING anything, they are looking at ADDING the ability to skip updates.
You can still incrementally update of course, there is no hint of dropping that.

Indeed! I was really surprised to read this headline, which implied that "incremental upgrades" are no longer being supported. It turns out, however, that the poster simply has a completely different concept of "incremental upgrade" than I do: For him, the normal upgrade is just "upgrade", and an "incremental upgrade" is when the distro forces you to upgrade in several small steps instead of one big step. The plan is to stop forcing you to take these small steps. And that's it! Upgrades - the normal upgrades that have always been supported - will NOT be dropped.

Comment Re:Rsync could have done this too! (Score 2) 150

Not exactly.

rsync will always have to go through the files and check. Trying to identify stuff like renames will obviously make a difference, but as it's only really going to have any sizeable impact when you happen to have lots of renames, but not actual data changes, it's probably not even worth the effort of implementing it.

The rename issue is actually *very* important. It's not likely that you'll have a lot of independent renames, but something very likely is that you rename one directory containing a lot of files - and at that point rsync will send the entire content of that directory again. I actually found myself in the past stopping myself from renaming a directory, just because I knew this will incur a huge slowdown next time I do a backup (using rsync).

Comment Re:Rsync could have done this too! (Score 1) 150

The crucial difference is ZFS send is unidirectional and as such is not affected by link latency. rsync needs to go back-and-forth, comparing notes with the other end all the time.

But this is *not* what the article appears to be measuring. He measured that the time to synchronize a changes were nearly identical in rsync and "ZFS replication" - except when it comes to renames.

Comment Rsync could have done this too! (Score 4, Informative) 150

Reading this article, it seems that this "ZFS replication" is very similar to rsync, with one straightforward addition:

Rsync works on an individual file level. It knows how to synchronized each modified file separately, and does this very efficiently. But if a file was renamed, without any further changes, it doesn't notice this fact, and instead notices the new file and sends it in its entirety. "ZFS replication", on the other hand, works on the filesystem level so it knows about renamed files and can send just the "rename" event instead of the entire content of the file.

So if rsync ran through all the files to try to recognize renamed files (e.g., by file sizes and dates, confirming with a hash), it could basically do the same thing. This wouldn't catch the event of renaming *and also* modifying the same file, but this is rarer than simple movements of files and directories. The benefit would have been that this would work on *any* filesystem, not just of ZFS. Since 99.9% of the users out there do not use ZFS, it makes sense to have this feature in rsync, not ZFS.

Comment Re:Disaster "surges" (Score 1) 75

In theory. In practice, the result is that the provider is strongly encouraged to under-provision their network so they can charge extreme rates for normal use, citing "high" utilization as an excuse.

Exactly. Moreover, it becomes impossible to compare prices of two competing networks. You can't say "AT&T charges me 10 cents a minute, Spring charges me 15 cents a minute, so I'll chose AT&T" - instead, one company might nominally say their price is 10 cents a minute, but during 90% of the day, or in the area where you work, it will claim there is congestion so it will actually charge you 50 cents a minute.

Comment Re:Mistake from C language 101 course (Score 1) 78

At least in my "C 101" class they said using rand() is good enough.
For this class.
I didn't know better than srand(time(NULL)) until the course in cryptography. Perhaps this just means my university wasn't "world class" :(

I guess you needed to also take the "advanced cryptography" course, where they would teach you that if you use stand(time(NULL)) and then make the time at that moment easily guessable (e.g., by leaving behind a file created at the exact same time), your supposedly-unguessable seed becomes easily guessable...

Comment Re:DRM Does Work (Score 3) 301

From TFS:

explains why cryptographers don't believe that DRM works

While I fully agree that DRM isn't foolproof, I disagree that DRM doesn't work. The reason DRM is being implemented is not to prevent all piracy ever - simply put, that's impossible - but rather to prevent common, casual piracy among low-skilled users.

That is a common misconception. When DVD CSS (the DRM on DVDs) came out, they claimed it was to stop piracy. That was a joke - it only took the effort of one pirate to strip out the DRM and create an unencrypted file, and from then on the movie becomes available to pirates, and "casual", "low-skilled" pirates started copying *those* unencrypted fils, not the original DVDs. All these pirates needed to know was how to copy files - they didn't need any special "hacking" skills.

Moreover, not only did CSS not stop DVD piracy, movie producer started to use it to limit users with things that have nothing to do with copying - for example region coding (you cannot play a movie you bought legally in another country) and unskippable ads (in some places in the video, fast-forward did not work). And who didn't have to suffer this crap? Of course, the pirates. The pirates - either copying files over bittorrent or buying a DVD from some pirate DVD manufacturer - will get a DVD without all that crap. What a wonderful business move.

It's gotten to the point where the first thing I do after getting a DVD is to rip it to an unencrypted file, delete the silly "FBI warning" and ads, and save that file. I don't need my children to see FBI warnings and ads before watching a movie I paid for. Nothing in "copyright" law allows the copyright holder to force me to watch this crap - any more than book manufacturers can force me to read the first page of the book every time I want to read it.

Comment Re:Who cares? (Score 5, Informative) 301

If JPEG finally implemented DRM, then more people would switch.

You are missing the point... Even if JPEG implements DRM, it doesn't force you to use DRM on the photos you create. You can still take photos, draw images, etc., and not enable DRM on them. So people who currently create JPEGs can continue to use them and don't need to "switch". The problem with DRM is when other people put them on the images they send you. E.g., you browse some website and you see there a DRMed JPEG. How can you "switch" to PNG here?? You didn't create this JPEG, someone else did it, and they did so deliberately.

What users can do, however, is to not even try to get their content from the official publisher (because it uses some annoying DRM) but rather get the same content from a "pirate" which broke this DRM and converted the content to a more useful format. This is what people have been doing for years for video. I, for example, never use actual DVDs any more (my living-room "DVD player" is stash away in the attic) - I always rip my DVDs to an unencrypted ".vob" file before watching them, and avoid all sorts of region locks, mandatory ads, and other crap the publisher thought he could force on me in the pretense of "copyright".

Comment Re:Yes - it worked in the Kibbutz! (Score 1) 563

But what you miss is your own admittance that it only worked for a few volunteers, not a whole society. You also seem to ignore your own admission that they collapsed after a brief period of time (in the grand scheme of history.)

According to the Wikipedia article, at its peak, 129,000 people lived in several hundred Kibbutzim - these were not just "a few volunteers". But you're right about the collapse. But in any case, it was a more interesting and realistic experiment in human nature than the fictional experiment on creating the Star Trek universe ;-)

Comment Re:Yes - it worked in the Kibbutz! (Score 1) 563

No it didn't
" At that point, the Kibbutz died"

But it did work very well, for many decades. And people actually liked it, and were proud of it - it's not like they were forced to be there.
Yes, it stopped working now (the Kibbutz article on Wikipedia is tedious, but the "Decline" section is very interesting), but it did work quite well when it did. And it was nothing like Soviet Russia which at the same time experimented with the same ideals but using different methods - and different outcomes (in Soviet Russia, people were murderd, starved and tortured. None of this happened in the Kibbutz).

Comment Re:Post-scarcity is fictional and will never happe (Score 1) 563

That's an interesting thought experiment but since we do not and never will live in such a post-scarcity society it is ultimately meaningless. Some form of money is going to be a necessity for the foreseeable future. There simply is no scenario whereby we would have access to every possible resource we would need without some for of currency making the economy work.

There is a difference between "need" and "want". It is conceivable that what we need will be available freely - food, lodging, etc. - but if people want more than what they got, the troubles begin (and scarcity will return). For example, imagine one random member of the Star Ship enterprise. He gets a room, food, entertainment, security - all for free. But what if one day he decides he wants his quarters to be twice the size he now has? *that* resource is scarce. What if one day he decides he wants to replicate 10 tons of gold, just because he likes gold, but the replicator capacity is limited? What if one day he wants other Enterprise employees to become his servants - but these people have better things to do? If he wants any of that, he will need money (or some futuristic equivalent). The only solution is for people to stop wanting what they don't have. It seems the Star Trek guys got this solved - I never saw anyone on this series wanting anything...

Comment Yes - it worked in the Kibbutz! (Score 3, Interesting) 563

Yes, it was tried, and it worked, in Israel - it was called the Kibbutz (https://en.wikipedia.org/wiki/Kibbutz).

The Kibbutz, a form of town popular in the twentieth century in Israel, were small towns where all the inhabitants worked together on some shared infrastructure, mostly agricultural (fields, cows, etc.) just like the Star Fleet guys worked together on their ship. Everyone had a role in the Kibbutz just like on the starship Enterprise: One person's role could be to milk the cows, while a second person grows wheat, a third cooks dinner for the first two, and a fourth would take care of the first three's children. No money was changed hand between any of these individuals. The kibbutz also had shared cars, collectively owned houses, etc. This arrangement worked pretty well for a long time, and did not involve any state coersion (unlike in the communist USSR) - people genuinely wanted to be part of their Kibbutz, and if they didn't, they were free to leave.

The Kibbutz lost its popularity as the economy in the rest of Israel improved, and people (rightly) started to feel that perhaps they could have better living conditions by making money outside the Kibbutz, and people started to leave, or worse - started to want to divide the Kibbutz's income unequally among them. At that point, the Kibbutz died. It still exists nominally, but not in spirit.

Slashdot Top Deals

Old programmers never die, they just branch to a new address.

Working...