kerpele
kerpele on Hacker News
Not sure where your information that n8 was supposed to run Meego comes from, but I remember working with the Nokia s60 team already early 2009 and they were using n8 protos at the time. It’s definitely possible that there were two parallel projects though.
On the other hand, Maemo, the predecessor to Meego, required a pen-like pointer to comfortable use at the time as the UI elements were designed to be small. Only after they completely overhauled the UI (and renamed the Linux based OS Meego) it could have worked on the N8.
I’m not a ship engineer but I do know that ships are not built to be suspended from the ends. I guess in the worst case the hull breaks which would mean the canal to be blocked for quite a while.
Threatening the researcher really is the cherry on top here
Works again. I wonder if the fix was just rebooting a server
Wow, looks like triplebyte profile settings page is full of dark patterns. Like, setting yourself as not interested in offers will forcefully revert back after a time period, and that even though there’s a checkbox for opting in to being shown to companies you can’t save the profile without giving consent.
:(
Not sure if you were serious or not but your comment seems like a nice example of what the article talks about
> The main class of failures that I am worrying about regarding the MTTR is the very same observable problem that you solved last week occurring again due to a lack of quality gates. To the customer this looks like last weeks problem was not solved at all despite promises to the contrary.
I think the quality gates mentioned in the article are the ones where you have a human approving a deployment. If you have an issue in production and you solve it you should definitely add an automated test to make sure the same issue doesn’t reappear. That automated test should then work as a gate preventing deployment if the test fails.
Posted by
kerpele on Monday February 17, 2020 @07:45AM
from the github.com dept.
Wow, this article made me realize I was a part of the very early generation game devs in Finland getting my first job in the industry in 2001. I was so young and naive then that I didn't understand how early it was.
Is it possible that the problem there is the amount of women starting studies in stem fields? I don’t have any numbers but anecdotal evidence of two Helsinki based schools in CS related programs had very lopsided gender ratios in bachelors and masters levels.
That's awesome!
Although, all copyrights are Apple's on that particular file. I wonder if everything's been done by the book.
If someone told the young Linux freak me back in the early 2000s that one day Internet Explorer’s rendering engine is based on the KDE rendering engine I would’ve probably died laughing and frozen in horror at the same time.
Yeah, I realize there’s probably nothing left if the old KHTML but it still does give me a chuckle.
I just realized my terminology was way wrong. Sorry.
You have Manhattan distance and you want Euclidean distance to make sure the path is always optimal. Execution speed should be the same or better in the average case with Euclidean distance.
Nice visualization!
I don’t think the algorithm is correct though. The heuristic seems to use Euclidean distance instead of “how the crow flies” and thus this implementation goes along the axis instead of directly towards the goal. This causes the algorithm to find the optimal route only occasionally and probably has little to no effect on average execution time.
Nobody has six hour workday and nobody thinks anybody has that. It’s only in the imagination of the writer of this marginally factual article.
Most people don’t have any leverage for these kinds of negotiations and would fairly likely get shafted if there were no laws to protect them
Most people probably aren’t willing to sacrifice themselves for the possible slight advancement of mankind. Especially laborers who are the ones most affected by work time limits.
I wasn’t alive when the work week was shortened to 5 days from 6 but it is my understanding that the conversation this sort of a proposal Sparks is the exact same as that proposal back then did. It’s kind of amusing.
I think the big issue with companies like Facebook is not that their development model moves too quickly for them to be able to react to their issues but that they simply don’t care. Facebook has known about the issues with privacy, hyper targeted advertising etc for years. You don’t need to move very fast to react to a fundamental issue in that timeframe.
Exactly.
I remember a few years ago I came across an article on a major car website that ranked four wheel drive as more important in winter conditions than proper winter tires. I personally don’t care if accelerating takes a little longer as long as I’m able to steer and stop, but I guess everyone has their own preference.
On the other hand, a machine will not get tired or bored where a human most definitely will if the diff is anywhere near that 500 lines
if their audience blocks ads this isn’t going to help, it’ll only make people mad. I know I’m upset.
I can’t believe Ars Technica would do this. Do they not realize who their audience is?
It's kind of interesting that a piece of legislation written hundreds of years ago will be used to decide something like this.
I hope the contract that sparked this whole fiasco is big enough to cover the ton of goodwill they've lost (and keep losing) over this issue.
I don't understand. Don't you have the site URL stored with the password to allow bitwarden to automatically find the password entry for you?
I use on Mac (Firefox & Safari) and iPhone, wife uses on Mac (chrome) and Android. Neither has had any issues in the past year and a half outside of mild confusion about the new Safari extension after Apple removed support for the old extension format.
I completely agree with this article. I've worked in scrum and kanban teams and also lead both kinds at some point. To me kanban is by far the better option for the exact reasons outlined in the article.
The point is that deadlines are bad for the people doing the work when they can't influence the amount of work. Not that deadlines should be removed completely, but they should be moved to a level where the amount of work can be influenced, namely project/product management. They should then, completely independently from the development team, adjust the backlog and/or deadlines in case the project schedule starts to slip. If the deadlines are needed because there are doubts that the dev team is not working as hard as they reasonably can then there are bigger issues that any project management method cannot fix.