Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Comment Secret service was lucky (Score 1) 88

This event dates from late September. As far as I know he was caught, before he could sell anything.

But, the Swiss Secret Service was lucky: The guy was caught because his bank became suspicious when he wanted to set up bank accounts to receive the future price for the loot.

The guy essentially walked out of the place with disk drives full of data. As he was the IT maintenance guy, he could pull this off without anybody getting suspicious. If your IT guy replaces 'broken' disk drives, everything is ok, other employees thought. As Switzerland is small, that department was small too, so there was a lack of resources.

Markus

Comment Desired outcome (Score 1) 440

You don't say what your desired outcome is.

If this was my data I would proceed as this:

  • Data chunks (like web site backups) you want to keep together: weed out / move to their new permanent destination
  • Create a file database with CRC data (see comment by Spazmania)
  • Write a script to eliminate duplicate data using the file database. I would go through the files I have in the new system and delete their duplicates elsewhere.
  • Manually clean up / move to new destination for all remaining files.

There will be a lot of manual cleanup, I think.

Comment Switzerland (Score 1) 999

The Swiss economy is still doing fine, finding work is not a problem. Salaries are good too, compared to Europe. The downside is that prices (especially housing near the economic centers) are high too. Quality of life is good too.

For an European, getting a work and residency permit is a formality so you'll have no problems there. You can get by in English initially and pick the local language up later (French / German / Italian, depending where you go).

Comment Re:What's your actual problem? (Score 3, Interesting) 284

Good uptime is great, but unfortunately very expensive in terms of hardware, software and manpower. Questions you should ask yourself: - What is the maximum allowable downtime duration ? - How many outages can you tolerate per year ? - What is actual cost to you of a one day/evening outage ? - How many such outages did you have with your actual infrastructure ? I think the best option in your case is to have two identical servers/PCs of good quality with two mirrored harddrives each in hot-swap slots. If a harddrive fails, you can carry on for the evening and replace it the next day. If something else fails you swap the SQL server drives into the second server/PCs and fix the problem later. This is simple enough that you can instruct someone by phone to do that, when you are absent yourself.

Comment Re:But... (Score 2) 295

This Google experiment proves that you can build a self driving car who can drive safely for thousands of miles on actual public roads. Yes, there are some additional conditions which are not practical (like the driving the path manually before to record a precise map), but it has been done.

Most drivers are not very much 'observing', I just read somewhere that the Blackberry outage caused vehicle accidents to drop by 20-40% in some Gulf states. Observing drivers, Ha !

Just compare how many accidents are caused by trees falling onto the street compared to texting.

The biggest problems to solve are the cultural, legal and liability issues.

Markus

Comment Re:But... (Score 1) 295

I'm very much in favor of my car driving instead of me. I'm sure it will drive safer and better. For me the daily commute is a chore and I'd be very happy to leave it to a machine.

I'm sure there will be viruses/sabotage. But I'm also sure human drives cause more accidents than viruses/sabotage will.

Markus

Comment Re:end of the HDD (Score 1) 253

> Even if you decided to maintain a VM system, the idea of a unified storage system (DRAM+DISK as one device) is pretty fascinating.

You can buy this from IBM since >20 years. It is called 'System/38', 'AS/400' or 'iSeries'. The system has a flat 64-bit address space and memory essentially serves as cache for disk.

Markus

Comment Such projects are based on estimations (Score 1) 36

Such projects are always based on estimated performance numbers. It looks to me like the estimated (and contractually signed) target performance was higher than what IBM could deliver in the budget envelope and the target timeframe. Probably the technology advance was not delivering as expected. As the U of Illinois was not ready to soften on some aspects to make it fit IBM had the choice of either delivering much more hardware at a loss or to pull out.

From my (limited) search it looks like the project was signed in 2008, so back then IBM estimated they can deliver a PetaFLOP for $200M in 2011. It looks like they were wrong.

I witnessed similar situation where the machine could deliver the promised performance using a benchmarking program, but real apps were unable to get to similar numbers. Improving the software stack made the performance available to apps, but it took 2 years to get there. The hardware was performing well, but immature software was spoiling it.

Markus

Comment Re:Duh? (Score 4, Insightful) 119

That is exactly what will not happen.

The ones who should tell their Customers about the problem is Siemens. But they will play the problem down because it might affect the sales of the next batch of stuff.

The evil hacker will just buy a bunch of systems, analyze it and find the vulnerabilities. This completely independent of the disclosure. Stuxnet was developed before this disclosure and I think the vulnerabilities used by Stuxnet are still there.

This is why security by obscurity does not work in the real world.

Slashdot Top Deals

"Ninety percent of baseball is half mental." -- Yogi Berra

Working...