Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

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:Its like normal web development, but worse (Score 1) 120

by jellomizer (#49360577) Attached to: UK Licensing Site Requires MSIE Emulation, But Won't Work With MSIE

I found found, it isn't about technical skills, but stupid decisions made from a group think process. While prevalent in all sectors government is the biggest offenders because government culture of "It is the mistakes you make which can hurt you" vs. Private which focuses more on your success. So government spends a lot of its time trying to figure out how many ways something can fail catastrophically, which could hurt their career.

So for this case, I get the impression that they put in a funky system to try to prevent bots from filling out the paperwork, because if they hear that their website allows bots to fill out licenses they could get in trouble. I am guessing they added this near the last minute of the project so the page was designed differently. Causing this complex stupidness.


Comment: Re:*sigh* (Score 1) 194

by jellomizer (#49360395) Attached to: Iowa's Governor Terry Branstad Thinks He Doesn't Use E-mail

No it is partisan politics.
If Hillary personal email server was really an issue, it would have brought up years ago before the start of the next presedential run.
But because she is a political threat it is a good discression that the republicans can make a fuss about, and this time the media is on their side, because they want access to her personal email. While the media touts government transparency they really want to see if Hillary is on good terms with Bill.

Now if Hillary stunk up the bathroom. The republicans will deny that they would never do that.

Comment: Re:Product Placement Taco Bell (Score 2) 18

by Xest (#49352795) Attached to: Ordnance Survey Releases Mapping Tools

So Slashdot shouldn't post anything about new product or data releases ever because it's product placement?

It's not like Slashdot is shilling for some ultra-rich company in this case that's just trying to make a quick buck off the user base here. Ordnance Survey is the UK government's official mapping agency - it's a government department, not a private company.

More governmental data being release to the public is a good thing, as it's a continued expansion of transparency and freedom to access data that the tax payer pays to produce in the first place. Open access to data is a big deal in the tech world right now, and it's exactly the sort of thing a tech site like Slashdot should cover as a result - this isn't a story about the latest iWhatever.

Comment: Re:Restrictive workplace policy (Score 1) 255

by itsdapead (#49350351) Attached to: Generate Memorizable Passphrases That Even the NSA Can't Guess

only 3 incorrect attempts locks the account and requires a call to the outsourced IT in India

I think we can safely say that such a system will completely eliminate brute force password-guessing attacks. What's Hindi for "social engineering"?

Meanwhile, any suggestions for what to say to an IT department who, every time a phishing message comes round saying:

"Your account may have been compromised, please go to <a href=""></a> to confirm your security details."

...respond by sending round a message saying

"if you think you may be affected, please go to <a href="">;</a> to confirm your security details."

...because the people who fall for these know how to spot a dodgey hyperlink, right?

Comment: Or the people can just act like adults. (Score 1) 323

by jellomizer (#49348611) Attached to: RSA Conference Bans "Booth Babes"

The problems with such rules, means the are plenty of work arounds,

In general booth babes are hired, because they know there are plenty of ongoers who still sexually are teenagers. And use them to attract people to their booth.

However what will happen they will have people dressed to fit the rules. However still be sexy, and they will flirt with the potentional customer anyways.

Comment: Re:You Congresscritters just don't understand (Score 1) 60

by jellomizer (#49345419) Attached to: Amazon Blasts FAA On Drone Approvals, Regulations

Insightful? More like hippy liberal corporation bashing.
Now this isn't some conservative rant. The FAA should be taking such things carefully, so not to cause problems. However, some of the rules are not focused on more agile aircraft development, where drones are involved there is less needs to verify personal safety, and changes to the drone technology shouldn't need as much screwenty. So unlike a Jet where they decided to change a component, as the safety of the pilot is a major concern, and such change should be completely reviewed. For a drone, just as long it fits in the recommended size and flight area it should be allowed more flexibility in changes without as much FAA review. Being that the overall risk of such changes is so small.

Comment: Re:people are going to be saying (Score 1) 726

by Xest (#49344253) Attached to: Germanwings Plane Crash Was No Accident

I'm surprised at this point there's not been more effort to allow remote override of aircraft such each plane can have it's autopilot enabled remotely overriding the pilot's actions. I know there's always the fear of hacking, but would that really be much of a threat if:

1) The worst you could do remotely was enable an enforced pre-programmed autopilot course.

2) The system was secure with a one-time key that's set on the runway by an authorised individual

If you put this equipment in an area of the aircraft that's inaccessible during flight I don't really see how this could be a problem? Surely if you've reached a point where radio and radar contact have stopped making sense, and the pilot isn't responding sufficiently, you should be able to remotely force a plane back on course against the will of the pilot in this day and age? It would even likely save lives in the case of cockpit de-pressurisation and so forth. I get that you wouldn't want to do this all the time because the pilot is always going to have better situational awareness and might need to do things manually, but when the pilot is the problem, doesn't this make sense?

Is there a fundamental reason why this can't/won't work or is it simply that there's not been enough will for or interest in this sort of thing yet? It seems odd that we're talking about releasing secure self-driving cars, yet the far easier problem of self-flying planes (that frankly is already a solved problem anyway in modern drones) seem to be out of the question right now.

Comment: Re:Couch programmers bashing again. (Score 1) 177

by Xest (#49343743) Attached to: Modern PHP: New Features and Good Practices

"multithreading can be used to implement async io but it is not a requirement, see node.js."

Oh god. Node.js uses IOCP, which implements a thread based model. Did you think it used magic or something?

No wonder you're posted AC, you're just embarrassing yourself. Acting as living proof that PHP developers are clueless. Well done, you've successfully proven my points throughout.

Comment: Re:Couch programmers bashing again. (Score 1) 177

by Xest (#49342819) Attached to: Modern PHP: New Features and Good Practices

Okay, so it sounds like I was right then after all if you're conflating curl hacks which require the spawning of a completely different process and a full blown TCP connection to achieve anything with an actual proper threading solution or async IO implementation (FWIW I find it amusing that you claim multithreading and async IO are completely unrelated things and then pretend curl is an async IO implementation- facepalm. You don't even know how PHP's curl library works).

I was going to reply in a bit more detail to everything in between, but then I got to this section of your post and realised it's fruitless as you don't even understand the basics:

"You're still going to spend 90% of your time waiting on blocking io. you can't complete your request until that io request is done, sure if i have 30ms of php code executing and a 180ms sql query I can use asynchronous io to make that entire request take 180ms instead of 210ms, but you're still spending the bulk of your time waiting for that 180ms sql query."

There's two problems with this:

1) You still demonstrate that your knowledge doesn't stretch beyond basic CRUD environments, you believe that everything you do on the web is simplistic web front-end, database backend CRUD type stuff. This is false, and if you had any worthwhile professional experience you'd know that a lot more typically goes on behind the scenes than my first website type setups (but that's probably also why you think PHP is acceptable, because you're not doing anything that matters).

2) On one hand you're talking about high throughput environments, and on the other you're talking about a process only handling one client at a time, which is what I was referring to when I talked about the PHP way. In more professional environments you don't need a whole new process for each concurrent request. That's a massive amount of unnecessary overhead, and environments like .NET and Java allow you to simply process other incoming requests in the same process whilst one is awaiting IO.

You seem to completely lack any grasp of the cost of firing up processes, as you seem to believe that spawning a process is an equivalently performant thing to do as firing off a new thread. It's sad, and you just prove my point that PHP folks only support PHP so vehemently because they don't know any better.

There's a reason that PHP stirs up hatred towards it more than anything else (well, except maybe Javascript) - it's because it's objectively shit, and the only ones that can't see that are those that are inexperienced and don't know any better. Languages like C# and so on just aren't even close to as controversial because for the most part they largely just work as you expect them to, and aren't as poorly designed.

Comment: Re:It depends (Score 3, Informative) 481

by jellomizer (#49336693) Attached to: No, It's Not Always Quicker To Do Things In Memory

In general writing to RAM is faster than writing to the disk. However there are things that get in the way of both.
1. OS Memory Management: So you making a small memory string to a big one. So will the os fragment the string, when it comes up to an other systems reserved memory spot. Will it overwrite it (Buffer overflow), will it find a contiguous larger memory block and copy the data there. Will it copy and move the memory slots to a new location away from the memory. Will this be happening preemptively, or when the error condition occurs, will all this stuff happen with a cpu cycle that is not sharing with your app. Also if you are low on memory the system may dump it to the disk anyways.

2. OS Disk management: A lot of the same concerns that memory management has. However a bunch of small request is easier to find free space, then asking for a larger spot. So they may be more seek time.

3. Disk Caching: You tell the program to append to the disk. The OS sends the data to the drive, the drive responds back Yea I got it. then the OS goes back to handling your app, in the mean time your drive is actually spinning to save the data on the disk.

4. How your compiler handles the memory. Data = Data + "STRING" vs. Data+="STRING" vs Data.Append("STRING") vs { DataVal2=malloc(6); DataVal2="STRING"; DataRec->Next = *DataVal2; } You could be spending O(n) time saving your memory where you can be doing in in O(1)

Now sometime I do change my algorithm to write to the disk vs. handling it in memory. Mostly because the data I am processing is huge, and I much rather sacrifice speed, in order to insure that the data gets written.

The universe seems neither benign nor hostile, merely indifferent. -- Sagan