> There exist plenty of genuine windows devs out there that use git, or devs that switch between OS'es for different tasks (myself included, I'd boot up windows to work on graphics/games)
Yes, but you probably shouldn't be running a code hosting platform on one of your developer workstations.
I'm pretty sure it would work from a client point of view (it's still git after all), just that they won't support you running their web app on windows.
Unfortunately, Fossil's web-facing part is somewhat neglected. Up to the point, that the issue tracker for Fossil itself has been practically closed and the docs moved out of the wiki...
I still use it as a nice dvcs though, mainly for the single binary file installation.
Where do you see docs outside of the wiki? (Duh, the rest of the internet...)
Also, where do you get the idea that the issue tracker has been closed? It's possible that the maintainer has gone on hiatus, and there's not as much activity as there was once, but I see they have fresh issues this week and a release just yesterday.
I think that Fossil is a terrific way to introduce anyone to command line, database, and scm who you intend to sell or gift with a 'database' of any kind. It's very odd to me how many people can't wrap their head around the concept of a file, or database, let alone ./configure; make; make install
I think that SQL is the most accessible language to those people, since it fits a simple grammar and statements end in semicolons, and the fact that Fossil repositories can come packaged into a sqlite database file means that two weeks after you got them to try using Fossil to keep their copy, there should be no magic left in the box, you can show them a database and they should 'get it'.
I have not tried this with anyone, but it should work... of course unless they just aren't trying...
Are you serious? Fossil's docs have been "embedded docs" for quite a long time now. Even the main page is served from a file within trunk (this is the url / redirects to):
For the issue tracker: just try to report an issue (without logging in with a dev account). It has been very long time now that Fossil is accepting issue reports only through email. It's quite an ironic thing to do for a project that's providing an issue tracker, isn't it?
So, is that the wiki or not the wiki? It says wiki...
I think you're only telling me things that sound like they've been done to prevent spam or addition of spammy content.
I get that a file in the trunk is not the wiki. There is a real wiki, with web browser controls, and it's not what they're using. But it says wiki, and if you're trying to edit it but not a Fossil developer, you're probably doing it wrong... you should have your own Fossil repo/server.
I'll admit I did not try to submit an issue, and I'm not using Fossil right now. I just use Git. My users don't want the timeline on their homepage. shrug
As I said, this is a file from trunk. It says wiki, because .wiki is the file extension for wiki-formatted files. Which you typeset in almost plain HTML, but that's another story.
And, actually, I am a Fossil developer. Or at least a whiner with a dev account. Believe me, I know what I'm whining about.
Finally, Fossil is not for homepages. I guess your devs like having a timeline on their Github...
The vast majority of libraries won't work with the new Due, and some older shields (like expansion cards you put on top) won't either.
The ATMega based boards are cheaper & are easier to get hold of.
Additionally, the Cortex I/O is 3.3V, not 5V tolerant which makes it easier to accidentally fry.
It's exciting stuff for experienced arduino users who like the ecosystem, but if you really want it I'd wait perhaps another hardware revision so the hardware & software stuff is properly in shape. I've been using arduino since the early days and, trust me, you don't want to be the first one hitting obscure preprocessor/compile bugs. You will also be amazed at the amount of performance you can get out of the little ATMegas when you don't have operating systems sucking up all your cycles!
Given current technology, airships are slow, and suck at handling high winds.
Ballistic transport would cost a lot more fuel than current methods, as you need huge amounts of energy to escape gravity.
Reducing lift-to-drag ratio (for sailplanes for example) boils down to increasing the aspect ratio (the ratio between the width of the wing and the wingspan) and selecting an airfoil with a high coefficient of lift over coefficient of drag (wings generate drag through flying, and the wings which generate the most lift aren't necessarily efficient, which is why planes have flaps).
See http://en.wikipedia.org/wiki/File:Drag.jpg for the different types of drag on an aircraft (the 'pushing stuff through the air' drag is called parasitic, and the 'side-effect of lift generation' drag is induced).
The problem is that by doing this, you increase the structural mass of the wing for a given lift as you need a longer wing. There is a point on the optimisation curve between increase in efficiency from AR & the increase in structural weight from longer wings. Boeing and Airbus have teams of people who do this stuff for a living.
There are also human factors involved, like airports being set up for a maximum wingspan, and people being unlikely to choose an airline with slower flights.
I don't doubt that Boeing and Airbus have a lot of smart people. My whole point is that there are things to optimize for besides brute efficiency. I'm sure you could do a lot better than a 787 in terms of gallons of fuel per passenger-mile. I'm also sure that such an airliner would never sell, because people don't want to take three days to cross the USA by airplane.
Not especially; according to MacKay (the original article's reference) they're roughly comparable now:
"To estimate the energy required to move freight by plane, per unit weight of freight, ...then [a 747's] transport cost is 0.45 g, or roughly 1.2 kWh/ton-km. This is just a little bigger than the transport cost of a truck, which is 1 kWh/ton-km....
"...This is a bit more efficient than a typical single-occupant car (12 km per litre). So travelling by plane is more energy-efficient than car if there are only one or two people in the car; and cars are more efficient if there are three or more passengers in the vehicle."
The original article is pretty bad; the answer to the title's question, "Can we build a more efficient airplane?" is nothing but a link to MacKay. The rest of the article entertaining lead-up fluff.
You seem to be responding to me as if I'm comparing airliners to other forms of transportation. I'm not. I'm comparing current airliners with imaginary ones that are more efficient. The article claims that we've basically hit the physical limit for airliner efficiency, while I maintain that this is nonsense, and while we may have hit a limit for efficiency while maintaining all of the other attributes we want, we certainly haven't hit the limit of efficiency period.
For example, an airplane with a 40:1 L/D (done in the 70s, easy today) able to carry half its empty weight in payload (nothing too hard there) will require about 0.3kWh/mile per ton of payload to maintain level flight. Even accounting for propulsion inefficiencies, that's way more efficient than the 747.
Why don't we have such airplanes? Not because it's somehow physically impossible, nor even technologically impossible, but simply because it's not worth the tradeoffs. Nobody cares about increasing the efficiency of air travel if the result is an airplane that's ten times slower than a modern airliner.
Can we build a more efficient airliner? Of course! To say "no" is to imply that modern airliners are optimized for efficiency above all other things, which is pretty much ridiculous on its face. Can we build a more efficient airliner while still keeping all the other stuff we want out of airliners, like a mach 0.8 cruising speed and global range? Well, that's a bit harder.
If this refers to me, I was not attempting to discredit anyone.
I wanted to ensure people didn't think this was another "they store passwords in plain text because they don't know what a hash function is" stories we see every few days.
If you are interested in password security, why not write an article about Tesco?
1) The app downloads your emails into their server.
2) Yes, they store that actual password. Which is ridiculous.
3) Yes, good for them for that, but still there are others where they store passwords. And that is not acceptable.
4) But that also means that they outsource the security part of things. Which doesn't lend faith to the idea that they know about security. And if someone realises how to control their application, all the passwords will be hacked.
5) Pidgin is stored locally. There's a difference. Not that I support it, but it's still better than someone storing my passwords.
> The app downloads your emails into their server.
They need to do that to back up the emails. The product may not be something you are interested in, but it doesn't mean the execution is flawed.
> Yes, they store that actual password. Which is ridiculous.
They have to in order to retrieve the emails. Blame the standards!
> Yes, good for them for that, but still there are others where they store passwords. And that is not acceptable.
See above
> But that also means that they outsource the security part of things.
> Which doesn't lend faith to the idea that they know about security.
> And if someone realises how to control their application, all the passwords will be hacked.
This isn't something with a black and white answer and I respect your opinion on this. I personally feel that they may know plenty about security and have decided that this is the most secure option. For example, I wouldn't write my own crypto, because I know enough about security to know how hard it is to do right.
they can't, unless the email service gives them oauth.
and even then allowing a 3rd party to backup your emails is a very dangerous thing to do. they say that credit card is more dangerous, i say no. for credit cards you can claim fraud.
when your email gets hacked, potentially your whole digital life is gone
Then what you need to write is, "I think that unproven email backup services are a bad idea", not, "these guys are idiots because they store a retrievable copy of your email credentials" which is necessary for the service that they are providing.
what they could have done is to allow users to autoforward their emails over to their servers or something. not impossible, but i'm not their employee and i'm not responsible for thinking up business strategies for them.
You can only archive incoming e-mails via autoforward, not drafts and not outgoing email (unless you use their mailservers, which is something completely different). If I want archiving for my e-mails, I have to give up my account credentials. You could actually do sufficient mischief with the archived e-mails, you don't need the account credentials in the first place. That sucks, but it's not their fault, this kind of service is inherently insecure.
Now, if you can demonstrate that this particular company has a particularly unsafe way of storing the passwords or the retrieved e-mails, then you're getting closer to having a valid point.
So what you're saying is that they should limit their market to those users that can successfully set up email forwarding, solely because storing passwords is bad.
Part of the service they're offering is that they'll restore the contents of your mailbox in case of accidental or malicious deletion. I have
and by storing the passwords, they are putting their users at risk. and we are in an era where email security means more than anything. it means access to all your services.
they should go think about how they can design a service securely before offering it.
in fact, seeing how your account was created to post that comment and seeing how it doesn't make sense, i would suspect that you actually work for them.
Everything he said makes perfect sense and I agree with it. A brief look at my HN profile should tell you I don't work for them. (Never heard of them before in fact.)
I think that you are practicing cargo cult security -- you're doing a cargo dance here over password storage mechanisms in a case where it doesn't apply.
Yes, but you probably shouldn't be running a code hosting platform on one of your developer workstations. I'm pretty sure it would work from a client point of view (it's still git after all), just that they won't support you running their web app on windows.