Don't the marines use helicopters and Harriers for this role?
A F-35 can't fly slow and can't take nearly as much damage as the A-10 can and keep going - this is a byproduct of how it was designed to fulfill several roles and the compromises this involves. The aircraft is vulnerable to light arms fire, runs a single, big engine which is easy to damage, can carry very limited ordinance due to its internal bay arrangement and can load only 220 rounds of 25mm ammo. By any measure it is a poor, poor CAS platform.
Now, don't get me wrong. Like i said, the F-35 might very well be a capable aircraft for other roles. Just not this one. The requirements for a fighter and a close air support vehicle are radically different.
I'd count pretty much everything better than what GNOME has. Explore. IceWM, Openbox, CWM, Ion. They're all nice.
Jesus, what's with all the butthurt script kiddies in Slashdot lately?
Look, i actually like Gnome 3 and it's fancy window manager. There might be better alternatives around, sure, but i just don't give a shit anymore. It is more than good enough for me as it is.
Keep in mind armors in modern tanks are mostly intended to ensure the survival of the crew. You might now be able to make a tank go boom (a.k.a "k-kill") with a GAU-8 run, but you can sure as hell end up disabling it.
...but, for my life, i can't figure how they want to replace the A-10 with it. There's simply no way a F-35 can fill in for CAS roles.
If the airforce wants a cheap close air support aircraft, they should really evaluate the Super Tucano. At $10 milion a pop they can write an entire fleet off as losses in the F-35 program.
That was my exact first thought. I'm far from an Apple fanboy, but why the hell is the story framed to sound like they're surreptitiously sharing customer data with the NSA or something
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.
Agreed. Keep in mind though Go is very reliant on the concept of channels and messages so you're not really expected to rely on concurrent access but it is, in the end, unavoidable on some situations.
Don't get me wrong, this is otherwise a valid criticism, but Go provides sane locking mechanisms to ensure safe concurrent access to shared resources so it's not the end of the world.
Agreed, but provided there're enough basic building blocks to do so. Ada, f.ex., supports operator overloading.
I'm not saying this cannot happen in Go - everything regarding generics on that language is pure speculation at this point. But it won't be easy to make it happen without some performance hit, IMHO.
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.
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.
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."
Slashdot Mirror
The sad thing is, Oracle is still by far the best RDBMS out there. Sometimes you do get what you pay for.
Duh, but it is not an Extreme Pro adapter. Don't you know anything about IT?
Not a physicist by any chance here, but how is this possible? I thought superconductivity was pretty much binary - either you are or you are not.
Don't the marines use helicopters and Harriers for this role?
A F-35 can't fly slow and can't take nearly as much damage as the A-10 can and keep going - this is a byproduct of how it was designed to fulfill several roles and the compromises this involves. The aircraft is vulnerable to light arms fire, runs a single, big engine which is easy to damage, can carry very limited ordinance due to its internal bay arrangement and can load only 220 rounds of 25mm ammo. By any measure it is a poor, poor CAS platform.
Now, don't get me wrong. Like i said, the F-35 might very well be a capable aircraft for other roles. Just not this one. The requirements for a fighter and a close air support vehicle are radically different.
A sad reminder of how the first sale doctrine is now a long forgotten memory.
Are users even getting a refund?
I'd count pretty much everything better than what GNOME has. Explore. IceWM, Openbox, CWM, Ion. They're all nice.
Jesus, what's with all the butthurt script kiddies in Slashdot lately?
Look, i actually like Gnome 3 and it's fancy window manager. There might be better alternatives around, sure, but i just don't give a shit anymore. It is more than good enough for me as it is.
Keep in mind armors in modern tanks are mostly intended to ensure the survival of the crew. You might now be able to make a tank go boom (a.k.a "k-kill") with a GAU-8 run, but you can sure as hell end up disabling it.
A "shitty popgun" firing 200 kilojoules rounds. You won't find a lot of tanks surviving a strafe of those.
...but, for my life, i can't figure how they want to replace the A-10 with it. There's simply no way a F-35 can fill in for CAS roles.
If the airforce wants a cheap close air support aircraft, they should really evaluate the Super Tucano. At $10 milion a pop they can write an entire fleet off as losses in the F-35 program.
That was my exact first thought. I'm far from an Apple fanboy, but why the hell is the story framed to sound like they're surreptitiously sharing customer data with the NSA or something
The Stream 11 is possibly the best laptop i've tried at that price point. Great little computer.
So, i never tried Linux on it, but i got a HP Stream 11 for my parents about a year ago. The bang for the buck ratio on that computer is amazing.
I had a X220 with 8GB RAM for a while as my travel computer. Gnome 3 ran beautifully on it.
Unlike the Mac Pro, which is assembled in Austria?
Yeah, about 4W at full load. Is that "a lot" these days?
Also, from what (little) i've read about Kaby Lake the improvements from Skylake are minor - power consumption is in fact expected to be identical.
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.
You can get a small phone mount for your bike. I used them in the past and they work great - there're even waterproof models out there.
Agreed. Keep in mind though Go is very reliant on the concept of channels and messages so you're not really expected to rely on concurrent access but it is, in the end, unavoidable on some situations.
sync.Mutex?
Don't get me wrong, this is otherwise a valid criticism, but Go provides sane locking mechanisms to ensure safe concurrent access to shared resources so it's not the end of the world.
Agreed, but provided there're enough basic building blocks to do so. Ada, f.ex., supports operator overloading.
I'm not saying this cannot happen in Go - everything regarding generics on that language is pure speculation at this point. But it won't be easy to make it happen without some performance hit, IMHO.
"Let's not pretend that go has some magic concurrency primitive that is anything other than a normal thread launched by the clone syscall."
\_()_/
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.
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.
Not quite, no. The entire generics discussion was in fact about Go.
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.