There are a half-dozen different groups of mainstream programming languages (and a bunch of oddballs). Within those groups, it's relatively uniform. Going between -- not the same.
Most people who make comments like this have only seen languages which differ in syntax, but many do differ in semantics.
Actually, I'd say mainstream programming languages differ more in syntax than in semantics. They're all ALGOL-like imperative, structured, procedural languages. Java, C# and Python might stick your objects on the heap while C and C++ might stick them on the stack, but the code looks and functions the same. And sure, some of these have classes and others don't, but it's not really a big difference.
1. There is large variation in TN displays. I'm very happy with the Acer TN panels I have at home. I find good TN gives me less eye strain than a lot of the IPS panels. IPS is the way to go for photo editing and similar tasks which require color calibration, but for coding, I actually prefer a good TN panel. Again, the trick is to find the right one. Try them at a store, for example.
2. Consider getting one 4k, and keeping the 1080p monitors. I have a 5 display setup like that. It works pretty well, actually. The 4k is great as a main display, and all the auxiliary stuff lives on the 1080p panels.
Right now I have an Acer 4K TN as my primary screen and it's extremely difficult to work with. And keeping the three HD displays I have around it is also problematic... the resolution difference always destroys the illusion of working on one seamless desktop... and the viewing angle has me need to turn the HD displays around and rotate their output so I'm "viewing them from above" ..
I like Bruce. I trust Bruce. However, as far as I can tell, this is a black box. There is no documentation on formats, protocols, and similar. I have no reason to trust the security of this system. The closest I could come would be to read the source code.
Sorry, should have mentioned a bit about that. The Password Safe format is public, open, and available here [1]. There's also plenty of code/libraries you can use to write your own clients, e.g. Javascript [2], Java [3], Python [4]. For what it's worth the core data encryption is done using the Twofish cipher. Hope that helps.
That both does and doesn't help. There is the format, which looks sensible. There are the protocols around it, key generation, salt generation, overall design, etc. which are not.
What actually scares me about the design is if my machine is compromised, an attacker can grab my Password Safe file (plus keylogs or whatever) and has access to all of my passwords. The design seems not very robust at a designs+protocols level.
(In contrast, right now, if a machine is compromised, it only compromises the passwords I've used from that machine).
I'm at a startup where I found out a junior hire -- worse in every way than myself and several steps down in title -- is making at least 30% more than I am. It's a strange position. I've started polishing my resume as a result.
Honestly, I just found out, and I am trying to figure out when and how to bring this up. It feels like there are several good timings for bringing this up:
1. When I've just delivered something of high business value
2. When the company is really needs me to deliver something of high value
3. Annual review
4. Right before quarterly/annual budgets
5. When I have a competing offer
I've asked for a raise, not too long ago, without any information in hand about competing salaries. That conversation did not lead to a pay increase. I found out -- not long after that conversation -- that the post-funding folks make substantially more than the pre-funding folks.
Salary aside, it is an excellent job. I enjoy working there, believe in the mission, and I am relatively unlikely to leave for a more lucrative offer. I think management knows that, which is why they don't feel the need to pay myself (or other early employees) market rates. Management pays the least an employee will work for.
I gave my company a choice: raise my salary/title to reflect the new hierarchy or lose me to a competitive offer. They fed me a line about how the company was making money, but not enough to raise everyone's salary (translation: we don't think you can get a competitive offer).
I took another job 3 weeks later for 25% more money + actual equity (not bullshit stock options).
Startups can be fun, but in terms of compensation, the early employees will get screwed over.
Management is hoping to keep employees happy by maintaining them in a state of ignorance, which never works. That is not a good sign.
Think carefully and explicitly about the decision-making processes that could have plausibly created this situation where people doing the same stuff get paid substantially different amounts. Think about the values reflected by those processes, and the odds that the company does not have some major storms ahead given the people at the helm.
I've worked at a few places where it was against the rules to talk about your salary. I asked the owner why (quoting what Spolksy had said) and I was told that if the employees know what each other earned, half of them would leave. I asked why some people were being paid more than others for the same job, and the owner told me, "Some people are better at negotiating than others." And I knew for a fact that I am terrible at asking for more, so it was time to look for another job. Shame really. It was a good job, but I'd always feel like someone had negotiated better than me and was earning an extra 20%
I saw a sheet of salaries for a random subset of employees. Pre-funding engineering hires were universally paid substantially less than post-funding hires. The way we're structured, there isn't an equity upside which would cover the difference. If this was a one-off, you could chalk it up to hiring error, negotiations, Dunning-Kruger with regards to estimate of my own skills, etc. However, even myself excluded, a few of our best engineers are being paid substantially less than people much worse than people hired later on. It was pretty universal.
Often it's simply dependent on when you were hired. Employers have to stay competitive but won't give you a raise if you don't express discontent. When wages trend upward new hires can often end up making more money.
Some employers, anyhow. But I think it requires a certain level of negligence or callousness. You might be able to save a little money on payroll. But I think that ignores the hidden costs in reduced goodwill, lowered trust, and higher turnover.
That's pretty much true, but in the more "responsible" startups an employee who's been around long enough would be compensated with equity (or the equivalent in benefits) to compensate for the difference.
You would be surprised about how few "responsible" startups there are. Most will never be responsible until they're under scrutiny. I've been with a few that actively derided the idea of compensating employees who were underpaid during the initial growth phases. They thought that because they'd agreed to help "build the business" that nothing more was owed in better times.
One of them got a lot of press as a successful startup and landed several new large contracts. Which is why, after a year of executive self-congratulations and bonuses, their lead developer, who had saved several failed projects singlehandedly, left for more realistic pastures. They only brought him up to just below market when he talked about leaving, had no intentions about rewarding him for past underpaid accomplishments (which were obviously investments on his part), and despite their poor compensation packages had an overly strict culture for non-executives. Management compensation was top priority, and retention was assumed - they thought people would just stay despite having better alternatives. Even if he stayed, he'd have to watch other people get screwed. He wasn't the first, and doubtless he won't be the last rat to abandon that ship. I left as well, seeing that they really didn't care about anyone who didn't have ownership and a briefcase.
It's really not that uncommon. Being at the top of a company requires only one of three things: luck, lies ("charisma") or capital. Quite a lot of new business owners get mislead by their own kool-aid. They start believing that their vague "vision" is the most important thing and treat the people who do the real work as replaceable cogs. They give no thought to training costs or productivity and have high turnover rates. Merely treating the staff better could have a huge and positive financial impact. They'd probably know about these management issues if they didn't defensively fire people who voiced dissent. But a fool and his competent staff are soon parted.
I agree with the overall sentiment of your comment. However, I think psychologists would disagree with the idea that charisma -> dishonesty, and I think holding such a viewpoint is damaging to long-term success.
Uber are testing out a new scheme where they penalize people for not working full-time hours by charging a much higher commission for the first few rides they take every week: http://www.wsj.com/articles/uber-tests-30-fee-its-highest-ye... They obviously don't want people to work for them part time. Lyft are doing the same.
The article also provides an explanation for this: "Uber, which started its business taking a 20% commission on all rides, has raised and lowered that rate in different cities depending on the supply of drivers and rider demand."
It seems that one way to deal with over-supply of drivers is to lower rate the rate even further, but they probably don't want to screw around with rates too much. Lowering them drastically might discourage drivers long-term, to the point where they find a different full-time job and swear off Uber.
I found this one of the most useful books I've read, but less so for the physics (which was mostly an intellectual curiosity), and more so for understanding how to write good code.
In it, Sussman shows you how to:
* Write a Lagrangian
* Symbolically convert it into Lagrange's Equations
* Compile those into native code
* Numerically integrate the with an optimized numerical algorithm to get a path of motion.
And all of this, with beautiful, clean, concise, simple code.
Correct. In contrast to Newtonian mechanics, Lagrangians and Hamiltonians completely describe essentially all fundamental laws of physics -- including things like quantum and relativity.
However, they are cumbersome to work with for some complex, compound phenomena, such as friction.
What in your life must have happened for you to actually believe such nonsense? Or do you have a financial incentive of sorts to try to make other people believe it?
1. The technical solution is trivial. You always have encryption, but http=self-signed cert, and no authentication, and no lock icon. https=CA cert, encryption, authentication, and lock icon.
2. There are strong government and corporate interests in being able to filter the open web. This closes the open web.
3. For the first time in my life, I have a comment on Hacker News or Reddit at -4. I've posted much more controversial things before (I do care about anonymity; I do use one-off cypherpunks accounts, so my post history won't indicate things). Good debate was virtually always well-received, up-voted, and not censored. The only exception was here, and one place where there was a strong, clear, well-financed astroturf campaign. That's one datapoint, but overall, the debate on the topic smells of financed astroturf rather than genuine grassroots.
I fully agree with #1, but how do you go from a currently-imperfect solution (which could be improved over the years, moving towards a self-signed cert default solution which by the way we are looking at in http/2) to "the goal is to reduce competition"?
Mozilla is one of the most consumer-friendly companies in the world, and all I can see is you trying to undermine their efforts. Are there issues with the current state of affairs? Sure. Are they at fault?
You've been downvoted because your comment reeks of gratuitous negativity, not because a debate is not welcome.
Step 1: Add support to Firefox for encryption when connecting on port 80. Call this HTTP, but have the protocol identical to HTTPS with self-signed cert. You negotiate that when you connect to the web server.
Step 2: Advertise to the community you'll be deprecating unencrypted on port 80 after 2 years time. Ideally, make patches to nginx and apache such that it's a small config change.
Step 3: Change behavior such that:
1. Port 80+old http+no encryption: Show a small warning
2. Port 80+encryption+self-signed cert: No warning. Also, unlocked padlock. "HTTP" in URL. Behavior as for current unencrypted web sites.
3. Port 443+encryption+self-signed cert: BIG SCARY WARNING.
4. Port 443+encryption+cert without identity: No padlock. HTTPS in the URL, but grey, and unlocked padlock.
5. Port 443+encryption+cert with identity: Padlock. Green. Name of organization. Indicated as trusted.
One of the problems with a push like this is that, aside from preventing open web, it also undermines the meaning of a cert. With initiatives like https://letsencrypt.org/, I a cert means I actually don't know who I'm talking to (at least in a legal sense -- I can identify the entity, and take them to court if they rob me).
To answer your question: I'm actually not too unhappy with the current state of affairs. I'd be more happy with the state of affairs I proposed above. I'm very unhappy with the state of affairs Mozilla proposes. I value an open web more than I do an arguably more secure one.
This stuff ain't rocket science. Mozilla has smart people. If it's being done a dumb way, there's a reason for it.
Cloudflare's free plan has SSL now, which a 10 year could utilize. While that opens up a potential MITM attack, I don't believe it's worse than having no SSL at all (others argue it is, on the premise that it creates a false sense of security).
AFAIK, you can't serve pages from S3 over HTTPS using your own domain name, but https://bucketname.s3.amazonaws.com/ works fine. So if you have some other way of serving your HTML pages, you can include other static assets directly from S3 without triggering browser mixed-content warnings.
