Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Doomed from the start (Score 1) 213

The main problem that killed (is killing?) smartwatches is not only the limited use scenarios for them - is that battery times sucks. 24-48hs is already miserable for a phone, let alone a device you are supposed to attach to your wrist. My watch is a Citizen EcoDrive: rugged, accurate and never ever needs recharging.

I have several acquaintances who stopped using their iWatches or 360s just because it is annoying to put it to charge every night next to their phones. Been thinking about buying a 360 from one of them because there're some interesting apps for pilots out there but, in the end, its more a novelty than anything else.

Comment Re:If the point was ... (Score 4, Insightful) 326

There's no proof that it has anything to do with Wikileaks, but in a world of IoT devices with no thought toward security, anyone who cares to do so can mount DDOS with the power of a national entity.

What's the point of doing what Assange and Wikileaks have been doing without any moral position? He isn't helping his own case.

Comment Re:Legal? (Score 2) 279

No, of course it is not legal to set a trap to intentionally hurt someone, even if you expect that the trap could only be activated by the person committing property theft or vandalism. Otherwise, you'd see shotguns built into burglar alarms.

Fire alarm stations sometimes shoot a blue dye which is difficult to remove or one which only shows under UV. Never stand in front of one when pulling the lever! But they are not supposed to hurt you.

And of course these booby traps generally are not as reliable as the so-called "inventor" thinks and tend to hurt the innocent.

Comment Re: But what is it used for? (Score 2) 252

Sheeze. Ok, to wrap it up: goroutines are not OS threads like you originally suggested. There's not a a clone syscall associated with every goroutine; in fact, you can limit the number of concurrent threads on a Go process to 1 if you like and have them all run under a single process. See GOMAXPROCS.

Now, the concept of goroutines is arguably much closer to what's commonly known as "green threads". But again, this is not what you originally stated.

Comment Re:But what is it used for? (Score 1) 252

I humbly disagree. Not like i have ran any scientific benchmarks on this, but from my limited experience Go binaries tend to be blazing fast.

Just found a site comparing different languages solving a number of computing problems. Now, i know these are to be taken with a grain of salt, but their results is that Go runtimes are comparable with C++ and way ahead of Java.

Comment Re: But what is it used for? (Score 3, Informative) 252

Let's not pretend that go has some magic concurrency primitive that is anything other than a normal thread launched by the clone syscall.

Oh, but it does - though i wouldn't call it "magic". Don't take my word for it: write a small program spawning, let say, 100000 goroutines. See how many system threads are launched.

From the documentation itself: "They're called goroutines because the existing terms—threads, coroutines, processes, and so on—convey inaccurate connotations. A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space. It is lightweight, costing little more than the allocation of stack space. And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management."

You're mixing up concurrency with parallelism. Rob Pike had a couple of very interesting talks on the matter.

Comment Re:But what is it used for? (Score 1) 252

Excuse me, but it is complete nonsense to suppose that inheritable classes or templates reduce performance, if that is what you mean by generics. In fact, in the hands of skilled programmers, templates are often used to improve performance. And inheritable types has nothing whatsoever to do with performance, again improving it if anything (by allowing you to express a design in a way that is both extensible and performant).

You're wrong. Depending on the implementation, generics can indeed come with a performance hit; the main example is Java, where type erasure and runtime casts are involved.

There's currently no generics support in Go but, based on what the language currently is it (statically typed, no operator overloading, type interference on variable declarations, etc.) a generics implementation will have to be "magic" in some way - that is, it cannot simply be implemented as a code rewrite before compiling.

Slashdot Top Deals

Base 8 is just like base 10, if you are missing two fingers. -- Tom Lehrer