Which usually isn't cryptographically secure. So now you need to audit the random number generator and make sure that it has no known holes, including obscure edge cases. And then you need to confirm that any implementation is correct and audited.
That quickly takes you down a rabbit hole, which may be why the contract was so expensive.
I agree that it can be interesting and useful to discuss flaws, but potential solutions are what make the discussion worthwhile. Saying "This will never work for X, Y, and Z reasons" creates a much less interesting debate than "This has flaw X, but I think it could be solved by this change. What do you think?"
It frequently appears that people react negatively on HN purely based on instinct, without doing any research. The response to Dropbox's launch is particularly illuminating:
https://news.ycombinator.com/item?id=8863 (I think that every Dropbox user can point out half a dozen ways it is better than FTP or a USB stick)
All of the criticism on the Dropbox post is addressable, but the discussion would have been a lot more interesting if the original commenters pointed out solutions themselves. That shifts the discussion from a feeling of "This will never work" to "Cool idea! Here's how you can make it better." The latter, and not the former, is important to the culture of HN.
Since the developers have been working on the app for three years, I'm sure that they've built in safeguards. One simple fix that comes to mind is to store all data locally, except for the database of abusive employers. If people want to contact lawyers to recover lost wages, all of the information in the app is kept private since attorney-client confidentiality kicks in. With something like that, there is no additional risk to using the app.
P.S. This is not a criticism of you or your comment, danielvf (I think that the point you brought up is valid). One thing that does bother me about Hacker News, though, is that the top comment is almost always a rejection of the innovation at hand. The hacker part of Hacker News should be about improving imperfect systems, not instinctively criticizing and rejecting them. I feel like HN would be a much more interesting site and much truer to its culture if every critical comment had to include a potential fix for the criticism. If someone can't come up with a potential fix to add, then they haven't done enough research to justify making the comment in the first place.
But one major benefit of Beartooth is that it allows for asynchronous communication, while traditional radios don't. That aspect could turn communication in remote areas from centering around crucial information only (since everything is immediate) to something closer to traditional casual text messaging. That's a big plus, and it makes a Beartooth a nice complement to traditional gear rather than a replacement for it.
I have absolutely no affiliation with Beartooth, nor do I own one. But I have gone on long hiking and canoe trips in rural areas and could see a Beartooth as a nice addition.
I have no idea why your comment is at the bottom of the page. So many arguments in this comments section set up a straw man, claiming that the author is saying that nothing should ever be configured. Of course, it's not that you never need configuration, it's that you should have sane defaults for very common use cases.
If you hear about Linux and want to install it, for example, Googling "Linux" just takes you to the linux.com homepage. Last I checked, it contained no links to distros. This is the same situation. Someone's goal is to install a Linux distro or to use nvm, so you should make it easy for them to install a Linux distro or use nvm. Don't make people wade through complex instructions for a process that should be simple.
Most software solves problems. Why add complexity when someone wants to get something else done?
I completely agree. People should make sure to look at the claims, particularly under 1 at C:
"rendering, on the computing device, the tab management area such that a close button of a remaining tab is located at the screen position, wherein the rendering (b) comprises, when the tab management area was determined to be full in (b), translating the remaining tab to the left such that the remaining tab maintains the same width"
This is a patent on Chrome's mechanism for resizing the tabs after you move your mouse away from the tab bar, which is nicer than the standard method of resizing them while other tabs are still being closed. It's not a patent on opening and closing tabs in general.
Disclaimer: IANAL, but I have worked directly on patents.
What is your reasoning? Getting press isn't easy, and it can greatly help a startup in terms of sales and contacts. Self promotion directly helps with that, and also opens up connections that would have been missed otherwise.
While that wording is more precise, the current wording is better for promoting the software. Ordering by market share makes sense, and users who are quickly scanning the page for compatability information don't need to make the connection between OS X or Linux and *nix, and can instead recognize their current system easily.
If this were documentation the change should be made, but it's probably not the right move on a website focused on promotion.
I see your point. I'd argue that programmers who are treated that way have bad managers, though, rather than it being a function of programming as a profession. I've never dealt with a company that hasn't given me some autonomy, though, so I can't really comment on that perspective.
A company can give programmers autonomy, or it can give them bits of information and treat them poorly. It could also do this for its sales team, its lawyers, or its marketing department. This strikes me more as a problem with the company rather than a problem with the nature of programming.
That's like arguing that surgeons are performing a blue collar job when they're given a diagnosis and test results from another physician. In theory they're performing the same repetitive motion, just like programmers are in theory creating an implementation to solve a given problem.
However, there are provably good and bad surgeons and provably good and bad programmers. The reality is that you're making a lot of decisions when you cut out a tumor or implement a spec, decisions which take skill and practice to get right. I certainly wouldn't want my surgeon to be a cheaper alternative, nor would I want a programmer working for me to be the same. Not all programmers or surgeons are equivalent, since there is a large element of skill and practice.
I use Trello, and then I have it sync with Google Calendar. That way, I can handle individual tasks with the flexibility that Trello allows, but use Google Calendar when I need a broad picture of due dates.
For me, to-do lists are far too limiting. Trello strikes the right balance, however, when it comes to customizability.
I meant the design, since the page created such a clear template that would be fantastic for future open source projects to modify. But if you want to release the content in the open too, all the better. I just think that a lot of open source projects which struggle with onboarding would be greatly benefited by using the page as a base.
I thought the same thing. The app store page shouldn't be the be-all and the end-all for discovery. Instead, it should be the last step in the marketing process. A promotional website, along with using mailing lists and social media as funnels, would go a long way.
Web apps don't hope that people stumble across them because there happens to be a centralized directory. The same active promotion used for web apps should take place for mobile apps.