Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Some things that make you go "Hmmm" (Score 1) 234

by grmoc (#46884855) Attached to: Toyota Describes Combustion Engine That Generates Electricity Directly

There were 2 of these 10Kw units required to cruise at 75Mph, so the efficiency, assuming 35% thermal efficiency, is 22mpg.

Given that they're small and easy to maintain, perhaps that doesn't matter if they're only backups, or if this is just a first-iteration technology that may get substantially better.

The big concern imho, is vibration. Unlike a crankshaft-based engine/motor, there is no physical coupling of the pistons if you deploy two of these in a horizontal configuration (as TFA suggests would counter vibration).
The lack of coupling means that the pistons are not mechanically synchronized, which means they don't create forces which act against each other.

I'd have to imagine that one could approximate the physical coupling by varying the timing and mixture, but.. I have no idea how actually effective that'd be.

Anyway.. vibration. Big deal.

Comment: Re:Investors? Really? (Score 5, Informative) 243

No, they are NOT investors.
If they were investors,they'd be in trouble with the FTC, which hasn't yet setup regulations allowing such.

People who use Kickstarter are pre-purchasing whatever it is they're being sold. That can act as income for a company, and thus a funding source, but that does not make people who purchase things via Kickstarter investors.

One of these days, we will be able to invest in this manner, but not yet.

Comment: Re:Investors? Really? (Score 5, Informative) 243

Kickstarter doesn't do investing. It is a pre-purchase...
I challenge you to find the word "invest" in the below (hint, it isn't there, nor is it *anywhere* on the Kickstarter page)

From Kickstarter:

Pledge $35 or more

  22997 backers

You will receive a digital version of the movie within a few days of the movie’s theatrical debut, plus the T-shirt, plus the pdf of the shooting script. Naturally, you will also receive regular updates and behind-the-scenes scoop throughout the fundraising and movie making process. Available to US, Canada, Australia/New Zealand, Mexico, Brazil, and Select EU countries (Now including Norway and Switzerland! See Project Description for full list)

Comment: Re: Abolish software patents (Score 4, Insightful) 204

by grmoc (#45946547) Attached to: Supreme Court Refuses To Hear Newegg Patent Case

The incentive to create is in the money you make from having written and either sold the service that you're selling, or selling the software itself, or sometimes just from the good feeling you get from having made something that works. The latter item is what inspires most really good folks, honestly.

Patents are horrendously ineffective at their intended purpose of incenting innovation in a world where non-practicing entities (read patent trolls) have a vast number of patents and exist with the *sole purpose* being to get money from those patents, and NOT to actually use them. Often the patent is granted (with the application having been secret) years after others have independently gone and done the thing themselves, thinking it was no big deal, probably because *it was no big deal*!
Even worse, many patent holders wait to sue until the idea (or company implementing such) is successful, maximizing the damage.

Worse, most of the patents these days (and there has been an explosion of patents... why orders of magnitude more patents when we're arguably no smarter than we were 10 or 30 years ago??) are fricking obvious.

And of course there is the fun bit that NO COMPANY CAN DO A PATENT SEARCH BECAUSE THEN IT WILLFULLY INFRINGES AND MUST PAY TRIPLE DAMAGES. So, noone looks at patents who actually might use them.

Patents, especially in the realm of software, do more harm than good today.
Strike that. They're almost purely harmful.

Comment: Re:Morons (Score 1) 141

by grmoc (#45397553) Attached to: Taking Google's QUIC For a Test Drive

TCP implementations are very mature. As impementors, we've fixed most/many of the bugs, both correctness and performance related. TCP offers reliable delivery, and, excepting some particular cases of tail-loss/tail-drop, knows the difference between packets that are received but not delivered and packets that are neither received nor delivered.
TCP has congestion control in a variety of different flavors.
TCP has various cool extensions, e.g. MPTCP, TCP-secure (not an RFC, but a working implentation), TFO, etc. etc.

You said streams. I agree that HOL blocking is solved by multiplexing over something, whether that be streams or connections, or messages.

That being said...
HOL blocking is NOT NOT NOT NOT NOT NOT NOT NOT solved with concurrent *connections*, because while doing so solves the HOL blocking problem, it opens up a greater number of cans-of-worms.
If one creates many connections:
I don't want to see more congestion in the connection startup phase since we're creating 60 connections (not an exaggeration) each with between 1-10 packets. I don't want to see poorer congestion avoidance because of the multiple connections. I'm tired of having each one of these connections land on a different server, and losing all ability to optimize what resources are being sent vs inlined because of the complexity inherent in attempt to rectify this. I don't want to have to expand the congestion window on X connections with short flows. I don't want to have to deal with tail-drop on X flows, etc. etc.

Comment: Re:Thank you (Score 1) 141

by grmoc (#45397485) Attached to: Taking Google's QUIC For a Test Drive

Wait, what? :)
Where was that claimed?!

In any case:
TCP's implementations are almost without fail doing per-flow congestion control, instead of per-session congestion control/per-ip-ip-tuple congestion control. This implies that, if loss on path is mostly independent (and that is what data seems to show), per-flow congestion control backs off at a constant factor (N where N == number of parallel connections) more slowly than a single stream between the same endpoints would.

So, indeed, sending several files in parallel has a potential for going faster when on links with independently correlated packet loss.

This sucks, by the way, because it makes the lives of those folks working on HTTP2 more difficult.

In case of injury notify your superior immediately. He'll kiss it and make it better.