Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Practical use? (Score 1) 48

by Rei (#49507405) Attached to: Mandelbrot Zooms Now Surpass the Scale of the Observable Universe

I don't think the Mandelbrot Set itself persay is all that useful, but its 3d relatives like Mandelbox, Mandelbulb, etc sure generates some amazing landscapes... I could totally picture that used in games or movies. It's amazing the diversity it can do with some parameter changes - steampunk machinery and evolving spacescapes, reactors / futuristic computers, art deco, extradimensional beings, alien cities, floating viny landscapes, transforming robotics, things hard to describe, etc.

I'd love to have a house / secret supervillain lair that looks like this one ;)

Comment: Re: "Surge Pricing" (Score 1) 70

by swillden (#49505663) Attached to: How Uber Surge Pricing Really Works

If I own a store and there's a civil emergency, I won't even open my store. I would use the products for the safety/survival of my family.

On the other hand if there aren't any silly laws in place preventing your from selling your goods at 10X the normal price, maybe you will only keep aside what your family really needs and sell the rest, thus making important goods available to the public when they're really needed. But if that's illegal, yeah, might as well keep them for yourself. When things get back to normal you can continue selling whatever you didn't use at the normal price -- same as you were able to sell it for during the emergency, but without taking the risk of selling something you might need.

Restrictions on scarcity pricing are a bad idea and serve only to create even more scarcity.

Comment: Re:Compensation delays? Hardly. (Score 1) 56

by Grishnakh (#49505563) Attached to: US Military To Recruit Civilian Cybersecurity Experts

The problem is that the government has pay grades. Fixed tiers of compensation. Those tiers work fine for most people. They're fucking useless for anyone exceptional that must be paid significantly more.

Why? Regular large corporations do pretty much the same thing with their engineers, and it works fine. They have "Engineer I", "Engineer II", "Engineer III", "Senior Engineer I", "Principal Engineer", etc. When someone gets promoted to a higher level, that puts them in a higher pay grade. Yeah, the corporations have pay ranges for those positions rather than fixed, exact dollar amounts, but the principle is the same. The government could do exactly the same thing.

No, this won't work for positions which are entirely up to negotiation. Most technical positions do not need to be like this. They just need to have pay grades and actually pay competitively with private industry.

Quote me, bitch. ... Can none of you fucks

Yeah, that's a great way to converse with people. Do you talk this way at work?

Star Wars Prequels

Star Wars Battlefront Game Trailer Is So Realistic It Looks Like Movie Footage 108

Posted by timothy
from the cgi-is-cheaper-than-actors dept.
MojoKid writes It has been a tremendous week for Star Wars fans. First we got to see Han Solo and Chewbacca make an emotional reappearance in the newest Star Wars: The Force Awakens trailer (the second official trailer Disney has put out). Now, Electronic Arts is treating us to a visual smorgasbord of cinema-quality footage showing the forthcoming Star Wars Battlefront game. Battlefront will support to up 40 players divided between the Rebel Alliance and Galactic Empire, all shooting it out and playing with some of the coolest Star Wars vehicles and weapons around. We're talking jetpacks, AT-AT war machines, AT-STs, TIE Fighters, X-wings, and more. Though the trailer allegedly shows actually "game engine footage," it's questionable whether or not it's actual gameplay or just pre-rendered cut scenes from the game engine. Either way, it's still pretty impressive.

Comment: Re:Copyrighting History (Score 1) 242

by swillden (#49504945) Attached to: Joseph Goebbels' Estate Sues Publisher Over Diary Excerpt Royalties

It seems that the bigger problem here is that modern copyright is so unreasonably long, historical documents are still under copyright. Anything over the original 28 year copyright term is really robbing the next generation of history.

While I know al copyright issues are sensitive on /. and hate going against the stream here, note that the next generation is not really robbed from history. They just have to pay for it.

Assuming the copyright owner can be found, and is willing to sell.

The basis for Eldred v Ashcroft was that the celluloid of many old films is rapidly degrading but because the copyright ownership is muddled it's impossible to find anyone from which the right to republish the films can be purchased, so the films are being lost forever.

Comment: Re:Ok.... Here's the thing, though ..... (Score 5, Insightful) 291

by swillden (#49504883) Attached to: Utilities Battle Homeowners Over Solar Power

The power companies are all moving towards "smart meter" technologies anyway. Why not make sure they've put one in that can monitor the output of a PV solar (or even a wind turbine) installation while they're at it?

For that matter, it seems perfectly reasonable to require the homeowner to install such a meter as part of a solar installation, as a condition of being able to sell power to the utility -- or even to push power into the grid at all.

Comment: Re:Compensation delays? Hardly. (Score 1) 56

by Grishnakh (#49504751) Attached to: US Military To Recruit Civilian Cybersecurity Experts

The exception is high demand labor of any kind. Someone able to run a company as CEO is going to get more money in the private sector than in the government's employ.

I don't think we're talking about overpaid suits here, we're talking about engineers and other technical people. The government is not known to pay them well either.

All those office workers are being paid better in DC than anywhere else in the country.

So basically a bunch of incompetent paper-pushers are being given largesse by the rest of the nation, and the economies in the rest of the nation would be better off if they seceded from the federal government, since they wouldn't have to spend so much funding all that waste?

Comment: Re:Why it is hard to recruit... (Score 2, Interesting) 56

by Rei (#49503837) Attached to: US Military To Recruit Civilian Cybersecurity Experts

The majority of major, targeted hacks (rather than just sweeping the net for vulnerabilities) - aka, the kind of stuff that the US military cares about - involves sending emails or making phone calls and introducing yourself as Bob from IT, and sorry to bother you but there's a problem that we need to discuss with you, but first a couple questions...

They don't need script kiddies, they need social engineers. Question number one in the job interview should be "Is your native language Russian, Chinese, Farsi, Korean or Arabic?" And even as far as the more traditional "hacking" goes, rather than script kiddies they're going to need people who are going to custom analyze a given system and assess it's individual vulnerabilities, people with real in-depth understanding. One would presume that in most cases that the sort of targets that the US military wants to hack are going to keep themselves pretty well patched to common vulnerabilities.

AIs doing hacking? What are you talking about? This is the real world, not Ghost In The Shell.

Comment: Re: It Has Begun! (Score 1) 51

by Firethorn (#49503747) Attached to: Resistance To Antibiotics Found In Isolated Amazonian Tribe

I remembered something about them digging up gut bacteria from something like 200 years ago in England - well before human use of antibiotics, and found that the gut bacteria in the corpses they exhumed were resistant to more antibiotics than modern versions.

But in looking for it, I found a study that they've found antibiotic resistances from 30,000 year old DNA from permafrost.

Which kind of makes sense. How did we develop penicillin? From Fungi. Which has been around for quite a while itself. Where did we develop many of our other antibiotics? By observing nature.

Comment: Re:What is wrong with SCTP and DCCP? (Score 5, Interesting) 72

by swillden (#49503565) Attached to: Google To Propose QUIC As IETF Standard

SCTP, for one, doesn't have any encryption.

Good, there is no reason to bind encryption to transport layer except to improve reliability of the channel in the face of active denial (e.g. TCP RST attack).

I disagree. To me there's at least one really compelling reason: To push universal encryption. One of my favorite features of QUIC is that encryption is baked so deeply into it that it cannot really be removed. Google tried to eliminate unencrypted connections with SPDY, but the IETF insisted on allowing unencrypted operation for HTTP2. I don't think that will happen with QUIC.

But there are other reasons as well, quite well-described in the documentation. The most significant one is performance. QUIC achieves new connection setup with less than one round trip on average, and restart with none... just send data.

Improvements to TCP helps everything layered on top of it.

True, but TCP is very hard to change. Even with wholehearted support from all of the major OS vendors, we'd have lots of TCP stacks without the new features for a decade, at least. That would not only slow adoption, it would also mean a whole lot of additional design complexity forced by backward compatibility requirements. QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself. It will make its way into the OS stacks, but systems that don't have it built in will continue using it as an app library.

Not having stupid unnecessary dependencies means I can benefit from TLS improvements even if I elect to use something other than IP to provide an ordered stream or I can use TCP without encryption and not have to pay for something I don't need.

So improve and use those protocols. You may even want to look to QUIC's design for inspiration. Then you can figure out how to integrate your new ideas carefully into the old protocols without breaking compatibility, and then you can fight your way through the standards bodies, closely scrutinized by every player that has an existing TLS or TCP implementation. To make this possible, you'll need to keep your changes small and incremental, and well-justified at every increment. Oh, but they'll also have to be compelling enough to get implementers to bother. With hard work you can succeed at this, but your timescale will be measured in decades.

In the meantime, QUIC will be widely deployed, making your work irrelevant.

As for using TCP without encryption so you don't have to pay for something you don't need, I think you're both overestimating the cost of encryption and underestimating its value. A decision that a particular data stream doesn't have enough value to warrant encryption it is guaranteed to be wrong if your application/protocol is successful. Stuff always gets repurposed and sufficient re-evaluation of security requirements is rare (even assuming the initial evaluation wasn't just wrong).

TCP+TFO + TLS extensions provide the same zero RTT opportunity as QUIC without reinventing wheels.

Only for restarts. For new connections you still have all the TCP three-way handshake overhead, followed by all of the TLS session establishment. QUIC does it in one round trip, in the worst case, and zero in most cases.

There was much valid (IMO) criticism of SPDY, that it really only helped really well-optimized sites -- like Google's -- to perform significantly better. Typical sites aren't any slower with SPDY, but aren't much faster, either, because they are so inefficient in other areas that request bottlenecks aren't their problem, so fixing those bottlenecks doesn't help. But QUIC will generally cut between two and four RTTs out of every web browser connection. And, of course, it also includes all of the improvements SPDY brought, plus new congestion management mechanisms which are significantly better than what's in TCP (so I'm told, anyway; I haven't actually looked into that part).

I'm not saying the approach you prefer couldn't work. It probably could. In ten to twenty years. Meanwhile, a non-trivial percentage of all Internet traffic today is already using QUIC, and usage is likely to grow rapidly as other browsers and web servers incorporate it.

I think the naysayers here have forgotten the ethos that made the Internet what it is: Rough consensus and running code first, standardization after. In my admittedly biased opinion (some of my friends work on SPDY and QUIC), Google's actions with SPDY and QUIC aren't a violation of the norms of Internet protocol development, they're a return to those norms.

User hostile.

Working...