Hacker News new | past | comments | ask | show | jobs | submit | tblair's comments login

The answer for the bad conduct is suspensions, but the PA fights hard to keep them toothless. I don't understand why they want to defend their member giving dirty hits instead of the one receiving them, but it certainly seems that way to me.


I think you're almost right. If the federal government built it and amortized the cost across every town/city in Canada then it could very well be cheaper. I think siblings are correct that a one off would be a mistake though.


> If the federal government built it

Things working the way they do, the government could not build a system that even approaches a service like Uber.


Anyone can build Uber. The hard part is their business model of convincing drivers to lose money working for you.


I know you're implying that they don't care anymore, but I think over-working leads to fatigue and rush jobs/corner cutting, which is a great way to end up with security flaws.


Ctrl-F has a 'Whole Words' option that should do what you want.

Edit: Oops, missed the same reply from xudongz


Not to be too uncharitable, but did you read the rest of their comment? The very next words are that they don't want to bring multiple devices.


Yes, but it starts out with the assumption that the devices have the same function, which they don't. In a similar vain, a laptop will not replace either.


It's a bit surreal.

You can now bring all this information and entertainment with you and it takes up less space and weight than any 2 textbooks I used at uni and people are concerned about an extra half kilo in-case they can't make up their mind if they want to play console games or watch TV that day on the train.

Of course their phone can do all these things as well but they need the bigger screen or something.


Reminds me of the people who think we'll be able to plug our phones into a dock and have a portable pc everywhere, there will always be trade offs.


If you can't admit there is a huge overlap between mobile touch screen devices your are just being silly.


Have you replaced you phone with your tablet/laptop or visa-versa? They're all mobile touch screens.


Of course. I used to use my laptop all the time to browse at the couch or watch netflix in bedroom. Now I just use my phone for those purposes.


It is in Rust, although I'm sure you can come up with something where the type system won't save you.


On the Kindle Fire we had a "secure enclave" bit of hardware so the files were encrypted with a key that was hard/impossible for users to get. I don't think regular android has anything like that, but they might use Widevine or something similar


Most Android implementations these days use something based on the ARM SecureCore to manage keys for things like device encryption.


The article basically makes 2 points, which are:

1. They are invisible in the source code

2. They create too many possible exit points

As a java developer I really don't find 1 to be a problem at all. Lots of people complain about checked exceptions, but they solve this problem. It's very easy to see which functions throw and which don't. I'd even argue that the invisibility that is there is a positive -- I usually don't want to think about the error case, but can easily trace the exceptional path if I do. I find that often functions need to go back up the stack to handle issues, in which case the exception control flow is exactly what I want.

Runtime exceptions, on the other hand, are invisible and can be an issue, but things like running out of memory, or overflowing the stack, well, I really don't want to have to write: public int add(int x, int y) throws OutOfMemoryException, StackOverflowException, ...

For 2, I find that they just create 1 extra exit point, which is back up the stack/to the catch handler. You could certainly abuse them to cause problems, but I personally don't find this to be an issue in practice.

I think that everyone agrees that unstructured flow of control is problematic, but checked exceptions do have structure, even if it's a bit of a loose one.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: