Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Comment Re: Greedy Corporation (Score 4, Informative) 214

At this moment of time I am replacing a motherboard. Will Windows 7 even boot off it? NO!

Bullshit.

No efi support or I should say limited and no I do not even mean secure boot.

Bullshit.

I am talking usb 3 which Windows 7 doesn't support.

Bullshit.

USB 2 in efi? No support or very limited. Sata in uefi mode? Nope. Exotic. Need 3rd party driver.

Bullshit that doesn't even make sense. What does Windows 7 have to do with it? Talk to your mobo and peripheral manufacturers.

Windows 7 will boot if you turn on csm aka compatibility support module which trashes your boot time.

No tablet support.

Also bullshit.

Comment Re:it's not the click that matters (Score 1, Insightful) 147

It's the keyswitch FEEL. Clicky or non-clicky, you want a mechanical keyswitch. There are many options now for people who want a non-clicky keyboard with good feel - check for a keyboard with Cherry MX Brown switches.

Mechanical switches are a poor replacement for buckling springs. It's a world of difference.

Comment Re:they should have asked ebay (Score 1) 150

As a buyer, eBay accounts are throwaway.
For things like Steam, where one chargeback could nuke / limit your whole account and the operators ignore all of your rights because "LOL VIDEOGAMES", create individual accounts for individual titles you're unsure about. Alternatively, don't buy from stores with shitty fucking policies.

Comment Re: What Fucking Decade Is It? (Score 1) 100

If you're using a term like "Big Data", you don't belong in the fucking building.
Relational databases are perfectly suited to extremely large and complex datasets. You just have to intelligently design your database. You can't just throw noise into a pot and expect useful results. Hadoop (map reduce) tries to do exactly this. If you care about correctness, completeness, and synchronization of data, it's trash.

Comment Re:What Fucking Decade Is It? (Score 1) 100

SQL server is based around the idea of small amounts of changes with data retention being long.

Assume a system throwing off 3mbs of data which many companies can have if they are aggregating simple stuff like all customers on the websites and sequencing page by page access to look for correlations. There are 28,500 seconds in a workday (more if you have multiple locations). That's 85.5 petabytes of data per day. You need to aggregate this data fast. SQL Server's engine isn't designed for that.

Or for example SQL Server doesn't handle queries against unstructured information. Imagine that each record has a field of text and you want to do joins based on fuzzy matching between these text fields. Even with a few gigs of data SQL Server will die.

Check your math on that, please. 8*3600*3 = 84.375 GB, not 85.5 PB.

Further, 85.5 PB per day is no problem if you can manage to write all of that out to disk (1037 GB per second non stop lol).
SQL Server 2014 handles .5 EB per database, so it's not a problem. And if your tracking 3 MB per second per user, you're tracking bots, not users - it would actually be cheaper to just log all packets at that point.

As for making sense of the data, SQL can handle all of it if you design your database sanely. Even if you don't, you can slap a full-text index on it (including "natural language" style indexes). You pay a penalty for your poor design, sure, but everything works.

Comment Re:Manufacturing Data (Score 1) 100

Something as simple as manufacturing data far eclipses this number every day. Think of every screw from every supplier in every product. Then tracking the reliability of this product through the entire lifecycle with self diagnostic tests. No, this is not for your toy made in china, but when it comes to real top end products that HAVE to work, then you need this kind of data to figure out what went wrong and fix it fast. That could save your company millions.

No, making your latest dot bomb app does not need this, but there are many places that do. Also check out financial apps like credit fraud, insurance, etc.

Every screw from every supplier in every product? No one dealing in volume tracks that because it's fucking pointless. People dealing with really-expensive shit that requires that tracking don't deal in volumes where it would be a problem.

But lets pretend we live in a fantasy world where that's true.

SUPPLIERS
ID - INT PrimaryKey, Identity
Name nvarchar(whatever) ...

PARTTYPES
ID - INT PrimaryKey, Identity
SupplierID INT ForeignKey (SUPPLIERS.ID)
Name nvarchar(whatever) ...

PARTS
ID - BIGINT PrimaryKey, Identity
PartTypeID INT ForeignKey (PARTTYPES.ID) ...

PARTTRACKING
ID - BIGINT PrimaryKey, Identity
PartsID BIGINT ForeignKey (PARTS.ID) ...

Add location/action/QC, result, timestamp, and employee id columns to the PARTTRACKING table and you get maybe 40 bytes per row total.

Pretend there are 100 tracking entries per part (LOL), 10,000 tracked parts per product (LOLOL), and 1,000,000 of these presidential spacecraft level products per day (LOOOOL).
You're only looking at 36 TB per day for PARTTRACKING, the most expensive (by far) table. Bump it up to 50 TB for all other shit in the DB.

Your claim was that one day of manufacturing tracking would far eclipse .5 PB. Not only is this not true, SQL Server 2014 has a limit of .5 EB, not .5 PB.

Further, .5 PB per day, even assuming non-stop operations, would be 6 GB per second of writing. And your claim is that that would be "far eclipsed".

Stop talking out of your ass.

Slashdot Top Deals

"Gravitation cannot be held responsible for people falling in love." -- Albert Einstein

Working...