Please create an account to participate in the Slashdot moderation system


Forgot your password?
Slashdot Deals: Prep for the CompTIA A+ certification exam. Save 95% on the CompTIA IT Certification Bundle ×

Comment Re: Programming (Score 1) 372

The one that bugs me the most is the imbalance between how society treats knowledge of humanities and sciences. If a scientist doesn't know about history, then he fits the 'ignorant scientist' cliche and is a figure of fun. If a historian knows far less about the science that his daily life depends on, then he's considered a cultured and well-rounded individual. And, in my experience, the humanities person who is ignorant of science is far more prevalent than the scientist or engineer who is ignorant of humanities.

Comment Re:Programming (Score 1) 372

First: NIST? Really? I guess you've not been paying attention for the last couple of years.

Second: You misunderstand the grandparent. If you don't understand the basic ideas behind a crypto algorithm (or, more importantly, crypto protocols) then you will pick the wrong one. No matter how good a cypher is, or how verified the implementation is, if used incorrectly it will still be insecure.

Comment Re:I don't see anything different. (Score 1) 121

Serif fonts work fine on small devices, they don't work well at low DPI. Which, in an age of 200+DPI on cheap devices, means that this move makes little sense. The only reason that the scaling is a problem would be if they're doing something stupid, like using a bitmap image rather than a vector. And, of course, a quick trip to confirms that they are, indeed, using a png rather than an svg (with png fallback if they care that much) for their logo.

So, the real story here is that, in 2015, web giant Google has yet to learn that resolution-independent images are a thing.

Comment Re:The same basic approach works everywhere (Score 1) 71

It's pretty easy on anything running X11, where the authentication of things that are allowed to deliver arbitrary input events to other applications is 'oh, you're a program that can read this user's home directory or from a trusted IP address? Go right ahead! By the way, if you're not then you're not allowed to put windows on the screen.' Windows has a similar mechanism, but has a special category of window that can only receive input from privileged components (i.e. real input devices and designated assistance apps). I filed a bug with Apple about the ease of spoofing the Keychain authorisation and privilege elevation dialogs against OS X 10.2. Maybe by 10.11 they'll fix it...

Comment Re:Yay for OSX (Score 1) 80

LLVM was originally developed as a research project at UIUC, by Chris Lattner supervised by Vikram Adve. It was offered to the FSF as a new optimisation framework for GCC, but the FSF turned it down. Chris was hired by Apple and they used LLVM for the CPU fallback path for their GLSL compiler (giving them a compiler that could target SSE and AltiVec and work on x86 and PowerPC, both 32-bit and 64-bit variants, reusing the same code for most of the implementation as the interpreter). In 2007, Chris began work on a new C front end and open sourced it. Initial work on Clang (basically getting it up to the point where it was as more-or-less useable C compiler, could parse Objective-C, and had a token nod at C++) was done entirely in Apple and then a lot of the development was done at Apple. A few of the other bits are still led by Apple people: the Clang static analyser is mostly developed by Apple people and the work on statepoints / patchpoints in LLVM was led by Apple's WebKit JavaScript team (though now there's a lot of work from people at Azul and MSR).

Comment Re:the comparison is pointless (Score 1) 80

If you're doing HPC, then you're definitely not the kind of 'desktop user' that the grandparent was talking about. For a single compute-bound application consuming all of the system resources, -O2 or -O3 will almost always win (unless they manage to blow out L1 i-cache on a hot loop, which does happen but is quite rare). When you benchmark systems with a lot of active processes, then the numbers become very different, because cache contention starts to matter (so does TLB contention, though on x86 with the hardware page table walker, fills are cheap if they hit in L1, so this boils down to cache contention again).

Comment Re:No Apple (Score 1) 92

Nonsense. The income that you'll get is number of people in the market multiplied by amount that you can get from each one. People with luxury yachts will spend a lot, but there are hardly any of them. If there are 4 times as many Android users as iOS users, but iOS users are willing to part with 5 times as much money (on average), then iOS is a better market to be in. Even if iOS users are only willing to spend 3 times as much, it's still a good market to be in because each customer likely adds to your support / accounting costs and having a slightly lower income with a quarter of the number of customers may be more profitable.

Comment Re:No Apple (Score 1) 92

You're talking about hardware makers. I'm talking about software vendors. If I make an iOS app and an Android app, what proportion of Android users will buy it, what proportion of iOS users will? If 4% of iOS users and 1% of Android users are willing to hand over money for it, then that's about the same amount from each platform. Numbers that I've seen are a bit out of date now, but they showed that iOS users were spending a lot more (per capita) than Android users, as most Android users only install free (including ad supported) apps, and ad revenue is far less than a direct sale can make.

Comment Re:How is this legal? (Score 3, Interesting) 299

There have been cases where EULAs that were not presented before the product was purchased were declared grounds for returning the product for a full refund. There is also a huge body of case law on contracts in general. In common law countries, the requirement for a contract to be binding is that a 'meeting of minds' has occurred and it is up to the party wishing to enforce the contract to prove this. Signatures, for example, provide strong evidence (and the backing of case law that they count as evidence), but there is very little statute law defining what makes a contract binding (though some on what makes one non-binding, such as requiring one party to break a law).

Comment Re:No Apple (Score 1) 92

How do those numbers change if you look at revenue? Last numbers I saw showed that the iOS ecosystem made about as much money as the Android one for app developers. If you have a small market, but that market has the majority of people who have disposable income and are willing to spend it, then it's not such a good idea to ignore it.

Comment Re:It's no ARMv8 (Score 1) 52

It depends hugely on the workload and it also depends a lot on the core. The ARMv8 ecosystem is quite diverse. For example, you have some players like nVidia's Project Denver, which fuses some of their GPU ideas with designs inherited from Transmeta. The Denver core is VLIW, but with staggered pipelines, so that results from one instruction in a VLIW bundle can be fed into the next (without needing rename registers, which are one of the biggest power sinks on a modern OoO CPU). When you start a program running, there's a simple decoder that turns ARM instructions into fairly inefficient VLIW instructions, but after a little while hot loops are optimised by a JIT and get a lot faster.

At the other end of the design spectrum, Cavium's Thunder X has 48 ARMv8 cores (not hyperthreads) per die, and supports dual-socket configurations for up to 96 processors per board. Individually the cores are weaker than a Xeon, but on some workloads (network routing, some database serving), they're pretty impressive in aggregate. That many physical cores also makes it easier to load balance VMs in a hosted environment. This is especially good for the kind of workload where most clients are idle for a lot of the time, but when they're busy they're very busy.

Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker