Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment Re:Can a Hillary supporter step up and explain? (Score 1) 634

Sorry for the Fox link, but here is an example of email that cannot be justified. People will die as a result of this.

"At least one of the emails on Hillary Clinton's private server contained extremely sensitive information identified by an intelligence agency as "HCS-O," which is the code used for reporting on human intelligence sources in ongoing operations, according to two sources not authorized to speak on the record."

Comment Re:Can a Hillary supporter step up and explain? (Score 2) 634

You say " the information in those emails was not classified at the time it was sent, then there has been no real wrongdoing here".

Demonstrably false. If the person had reason to believe the material should be classified then they are obliged to treat it as classified.

Given that we know some e-mails were SCI-level intelligence, there is reasonable suspicion she should have believed it should be treated as classified.

If you disagree, is she really competent to be reading classified material in the first place?

Comment Re:Take back Slashdot (Score 1) 1307

I support AC. I used to moderate extensively but ever since I gave +5 to "fuck beta" posts I lost my mod points. Don't know if I was somehow banned behind the scenes from moderation, but ever since then I've posted AC because there was no point in signing in.

Slashdot moderation is unique, and far preferable to reddit.

Please leave AC and moderation unchanged. Thanks!

Comment Re:Not a big deal... (Score 2) 458

No, not necessarily. The problem isn't so much the cpu cores, those will be mostly backwards-compatible. The real problem are all the other discrete PCI devices. If Microsoft does not provide updated drivers for their older OS releases, those older releases have no chance of working on newer hardware.

For example, Intel's Skylake chipset has I219 gigabit ethernet now (uprev from I218 which itself was an uprev from I217). The chance of older ethernet drivers working with newer chips is zero. In the case of the I219, the flash mapping and access mechanics changed drastically.

The integrated GPU is another good example. Skylake is up to Gen9. The chances that Gen8 code will work with it are zero.

One can go down the list. The only chipsets which are generic enough for older drivers to work are going to be the USB and AHCI chipsets. Everything else? Forget it.

But I don't know why people are complaining so much. The same can be said for BSD and Linux distros. An older BSD or Linux release is not going to work on newer systems. Most people don't care since they just update to the latest. While it is possible to backport the drivers to older OS releases, not very many people have the skill required so for all intents and purposes you need to run newer OpenSource OS's on these newer chips too.

-Matt

Comment Re:Energy consumption is going to increase (Score 1) 645

The problem with projections is that they rarely predict how things will actually develop. What happens in reality is that society slowly recognizes that a problem is present. Often too slowly (and probably too late when it come to climate change), but never-the-less it eventually gets recognized, and society shifts and adjusts.

Nobody seems to understand just how huge the energy economy is in the developed world, just to support our current life-style. The numbers you quoting, despite being probably wrong (very wrong most likely)... still, the numbers you are quoting are *nothing* compared to the energy infrastructure that drives the U.S. economy today. On a relative measure, if we can have what we have now, we can certainly achieve anything you've mentioned above.

At some point in the last 10 years this whole 'thorium reactor' movement cropped up, and frankly its hard debunk the utter stupidity of the model because very few people talking about it are bonafide scientists who know what they are talking about. Me included, on this issue. But on the other-hand I'm probably one of the few people who actually knows how to use a geiger counter and has had conversations with scientists standing in front piles of lead shielding crap I wouldn't want to touch with my bare hands.

When one of those guys tells me that thorium is a disaster due to its secondary byproducts, I believe him.

-Matt

Comment Article is kinda pie-in-the-sky wrong (Score 3, Interesting) 100

At least, not totally correct. Memory bus non-volatile storage such as Intel's X-Point stuff still requires significant cache management by the operating system. Why? Because it doesn't have nearly enough durability to just be mapped as general purpose memory. A DRAM cell goes through trillions of cycles in its live time. Something like X-Point might be 1000x more durable than standard flash, but it is still 6 orders of magnitude LESS durable than DRAM. So you can't just let user programs write to it however they like.

Secondly, in terms of data-center machines becoming obsolete. Also not correct. SSDs make a fine bridge between traditional HDD or networked storage and something like X-Point. For two reasons: First, all data center machines have multiple SATA busses running at 6GBits. Gang them all together and you have a few gigabytes/sec worth of standard storage bandwidth. Secondly, you can pop nVME flash (PCI-E based flash controllers) into a server and each one has in excess of 1 GByte/sec of bandwidth (and usually much more).

Third, in terms of memory management, paging to/from SSD or nVME 'swap' space, or using it as a front-end cache for slower remote storage or spinny disks, already provides servers with a fresh new life that means they won't be obsolete for years to come.

And finally there is the cost. These specialized memory-bus non-volatile memories are going to be expensive. VERY expensive. To the point where existing configurations still have a pretty solid niche to play in. Not all workloads are storage-intensive and these new memory-bus non-volatile memories don't have the density to be able to replace the storage required for large databases (or anywhere near it).

So, the article is basically a bit too pie-in-the-sky and ignores a lot of issues.

-Matt

Comment +1 for Mairix (Score 2) 177

After trying several solutions I settled on Mairix. Searches are screaming fast (less than a second to search several hundred thousand emails), indexing is fast, it's reliable (no problems in the 5+ years I've been using it), and the search language is easy and flexible.

* I use procmail to send a copy of everything to an archive, rotated monthly
* The archive is therefore just a handful of mbox files
* I have a cron job to run "mairix -Q" every 5 minutes, and "mairix -p" nightly
* I have this in my .bashrc: "function search() { mairix -o $$ $* && mutt -f ~/Mail/$$ ; rm ~/Mail/$$ ; }"
* And here's my .mairixrc:


base=~/Mail
database=~/.mairixdb
mbox=archive-*
mformat=mbox
omit=spam

With the above, I can find:

* everything from slashdot in the last two months: search f:slashdot d:2m-
* any emails I sent containing "squishy" in the body: search f:subreality b:squishy
* messages with "password" or "passwd" or similar in the subject: search s:passw=
* get a quick summary of the search language: search -h

It's so good that I download all my email from my work Gmail account so I can search it... sometimes Google's search just isn't precise enough to find what I need.

Comment Censorship is not the answer (Score 2) 452

Creating a widespread system of censorship is not the right approach:

1) It violates the principles the United States was founded on.
2) Suppressing the free flow of information deprives people of the liberty to make their own informed decisions.
3) When other opinions are squelched, the communication channel becomes a propaganda channel and loses all credibility.
4) This infrastructure will be abused. Now, ISIS. Next, common criminals. Eventually, dissidents.

Comment Re:Have they moved to LLVM/Clang? (Score 4, Informative) 26

LLVM/Clang builds the DragonFly world and kernel but does not yet build the boot loader. It can be brought in via dports. So it isn't 100% yet but very close. When it does get to 100% it will become one of our two officially supported compilers. Those are currently gcc-4.7 and gcc-5.2.1.

Wayland support isn't really up to us, but there is wayland support in XOrg that I think works for programs desiring to use that API. Don't quote me on it though.

-Matt

Comment Re:Gorbachev's off the cuff comment I heard live (Score 1) 210

What should not be forgotten is how bad the CIA estimates were on the Soviet economy. They were utter crap. I cannot stress this enough, and I encourage anyone interested in the topic to read the highly-rated (at the time) US texts on Soviet economy.

Virtually all highly rated US texts in 1980-1999 on Soviet/Russian economy were garbage.

So, what does this say about the CIA?

Comment Re:Don't Use UTC (Score 2) 143

Are you sure YOU know the difference between UTC and GMT?

It's not that UTC sounds cooler... It's what we actually use. UTC ticks based on atomic clocks and it's what's distributed through NTP. GMT (really UT) tracks Earth's rotation, doesn't have a stable second, and there are no high-precision realtime references.

Most programmers just need to know the number of seconds since Midnight, Jan 1, 1970, GMT, as God intended.

time_t doesn't count the number of absolute SI seconds since the Epoch: it assumes days are always 86400.0 seconds long, and completely ignores leap seconds... even worse, before 1972 they used sub-second leaps, so the offset isn't even an integer.

So, all told, why not refer to it as UTC since that's actually correct?

Comment Re: 20 cores DOES matter (Score 1) 167

If we're talking about bulk builds, for any language, there is going to be a huge amount of locality of reference that matches well against caches. shared text RO, lots of shared files RO, stack use is localized (RW), process data is relatively localized (RW), and file writeouts are independent. Plus any decent scheduler will recognize the batch-like nature of the compile jobs and use relatively large switch ticks. For a bulk build the scheduler doesn't have to be very smart, it just needs to avoid moving processes around between cpus excessively so and be somewhat HW cache aware.

Data and stack will be different, but one nice thing about bulk builds is that there is a huge amount of sharing of the text (code) space. Here's an example of a bulk build relatively early in its cycle (so the C++ compiles aren't eating 1GB each like they do later in the cycle when the larger packages are being built):

http://apollo.backplane.com/DF...

Notice that nothing is blocked on storage accesses. The processes are either in a pure run state or are waiting for a child process to exit.

I've never come close to maxing out the memory BW on an Intel system, at least not with bulk builds. I have maxed out the memory BW on opteron systems but even there one still gets an incremental improvement with more cores.

The real bottleneck for something like the above is not the scheduler or the pegged cpus. The real bottleneck is the operating system which is having to deal with hundreds of fork/exec/run/exit sequences per second and often more than a million VM faults per second (across the whole system)... almost all on shared resources BTW, so it isn't an easy nut for the kernel to crack (think of what it means to the kernel to fork/exec/run/exit something like /bin/sh hundreds of times per second across many cpus all at the same time).

Another big issue for the kernel, for concurrent compiles, is the massive number of shared namecache resources which are getting hit all at once, particularly negative cache hits for files which don't exist (think about compiler include path searches).

These issues tend to trump basic memory BW issues. Memory bandwidth can become an issue, but it will mainly be with jobs which are more memory-centric (access memory more and do less processing / execute fewer instructions per memory access due to the nature of the job). Bulk compiles do not fit into that category.

-Matt

Comment Re:No kidding (Score 2) 103

The fact that you get /a/ face isn't profound, but the resulting image is interesting. It gives a good picture of the things that human vision uses to locate faces: obviously the eyes and mouth are most prominent; there's moderate contrast for the cheekbones and nose; the oval shape is only vague; the neck, ears, eyebrows, and hairline are almost entirely missing.

I expect those are already well known to vision specialists, but to me, it's an interesting analysis of the exact details which make an inanimate object become a face.

Slashdot Top Deals

The secret of success is sincerity. Once you can fake that, you've got it made. -- Jean Giraudoux

Working...