diegoveralli

My anecdote is a bit different, I got a Tuxedo Pulse 15 Gen 2, and during the first few months I had overheating while charging, keys that would get stuck in pressed mode (which happened even in the UEFI menu), and the occasional black screen.

All of these issues went away over time and it's been running very smoothly for the last 18 months or so. Everything just works, and battery life is quite good.

The feel of the keyboard unfortunately cannot be fixed, and the built-in microphone sounds terrible, but with all the other issues gone, and very little need for a built-in microphone, I'm more or less happy with it.

Maybe what they mean is that, despite an asymptotic advantage, the new algorithm performs worse for many use cases than the older ones. This might be due to the many heuristics that solvers apply to make problems tractable as others have mentioned, as well as good old software engineering optimization.

So the work that's required is for someone to take this algorithm and implement it in a way that levels the playing field with the older ones.

I can't say using vendor specific icons is wrong, clearly a lot of people need just that, but I always miss more generic architectural components in these diagramming tools.

That's the problem I have with the `diagrams` Python package (https://pypi.org/project/diagrams/), I find it extremely useful, but the "Generic" section doesn't even include a "Queue" component, and the "OnPrem" section only includes specific queue products.

That Python package is exactly how I like to create diagrams, so I keep using it, but I always have to add my own badly-designed custom icons to it, which look so bad that I wouldn't dare send a PR to add them upstream.

To be clear, while I believe focusing on high school has a negative impact on diversity, I don't think this is intentional on Canonical's part.

Also I should say the overall recruitment process works, I was not the right candidate for the job, and the job wasn't right for me. But I think there were much stronger signals pointing to that during the process than what I did during high school.

I don't know whether it's a deliberate strategy but this definitely happened to me during my interview with Canonical this year.

From a diversity perspective, putting any focus on teenage years will probably select candidates from a privileged background, or people who have re-written their past into the award-winning narrative that's implied by the questions.

But maybe I'm wrong, maybe someone could answer the question "what was your biggest achievement during high school" with "I got clean", "I ran away from an abusive parent" or "I spent all my teenage years being bullied, and survived a suicide attempt" and they'd land the job.

Finally, Google Maps seems more intent today on showing bars, restaurants, ads, and work-from-home businesses than useful map-related features. Sometimes it doesn’t even show the most basic information anymore, including street names.

I suspect they arrived at this through a series of A-B tests, since the more useful navigational information they display, the easier it is for the user to "learn" a city, and be able to navigate by themselves. So hiding information that allows the user to learn the map layout probably increases usage metrics.

A couple of years ago I noticed I missed precisely that: "learning" the layout of a city when I travel. So I started using Organic Maps, which always shows street names and other useful information to assist me in my navigation, instead of guiding me turn by turn.

Search results are a lot worse than Google Maps, and the routes it picks are also often worse, and it's missing traffic information. But when I'm travelling I'm usually on foot, and I'm there to get lost and discover the place, so it's OK if my route is not as efficient as it could be.

Public transportation still requires you to go to the bus stop in the rain.

I want to say here that this comment sounds extremely alien to me, to the point that out of context I would have taken it as satirical.

I know you're serious, but there's probably a big portion of people to whom discussing the problem of walking in the rain to the bus stop sounds completely ridiculous, in any context, and as as something we must consider when talking about climate change policy, well, even more ridiculous.

I've lived in rainy places, and you just wear a raincoat, boots, maybe an umbrella (not always), and carry on.

This kind of disproportionate weight assigned to even the smallest levels of personal discomfort, when discussing these problems, is what most people are denouncing here. And this bias might be what pushes people towards techno-solutionism that doesn't have a chance of actually solving our problems in the time frame that we need.

The saddest part is how a lot of technical work goes to waste, because Packt won't give authors even the bare minimum technical review and copy-editing support.

I started reading "Mastering Linux Device Driver Development" a while ago but I found it to be almost unreadable, and I gave up after a couple of chapters. On top of the at times incomprehensible grammar, I found a few too many errata in the form of "can" vs "cannot", "only by" instead of "by only", etc... that change the meaning of the text significantly. It was too much work to pause every time I found the text confusing, to figure out what the author really meant.

Npm didn't support lockfiles until version 5, released in 2017, Yarn had them at launch in 2016. Before that committing node_modules was often used as a form of vendoring, to get reproducible builds.

If a new project these days commits node_modules to git, it's likely a mistake, but for legacy projects started before 2017 it was the lesser of two evils.

Edit: spelling.

The code is here: https://github.com/diegov/searchbox

But don't let its attempt at a friendly README fool you, it's personal-grade software of "works-on-my-machine", and barely, quality.

If you want to look at something more polished, I think https://github.com/amirgamil/apollo and https://github.com/thesephist/monocle are worth taking a look.

Also there's the https://github.com/karlicoss/HPI library, which you could build on, though it mainly relies on data dumps from the different services instead of crawling and fetching through APIs, which is why I didn't use it. Keeping up with API changes is bad enough, I don't want to deal with undocumented dump formats...

At my previous company there were several attempts to build declarative migration systems, one of which was more or less successful. They were all a lot more modest in scope and goals than Atlas.

The motivation is very straight forward: if you work in data management with different schemas, you often see similar migration patterns, so it makes sense to try to build abstractions representing these patterns.

If you couple this with the usual problem of the migration / schema duality, and some people who want to have a replica of the current state of the schema in the codebase in some way ("desired state"), you can see how we end up with schema-diff migration tools.

Whether these tools work well or not I think depends on the rate of schema changes vs size of the data store. The larger the dataset, the more specific you need to be with the migration strategies, so if you're not making schema changes very often, using a "clever", schema-diff migration tool adds risk for little benefit, and you might need to bypass the tool on a regular basis.

I don't work in a scenario in which such a tool would bring benefits, but there are projects that have frequent schema changes and data sizes small enough that you don't need to do anything special to maintain availability during migration.

I scrape all my bookmarks, github / gitlab stars, favorite tweets, etc... regularly, and push that to an elasticsearch instance, so that I can do full text searches later.

This is the only reliable way for me to find something I have a vague recollection of, which happens quite often. In the past I used to simply type whatever I could recall into Google search and often find it, but that just doesn't work any more. It's not just the SEO stuff, also the bias towards recent content seems to have increased, and obviously the pace of content generation as well. The haystack is much bigger now than it used to be.

Native comp is great. Most of the speed ups are modest, but it's really noticeable in some really slow operations.

For example, calculating org-table summaries in a very large org file I have (way too large, but I'm too lazy to archive) used to take over 5 minutes. Since I enabled native_comp it completes in under a minute.

Same here, it's very useful for waterfall scenarios but I've never used it for agile planning and I'm not sure it would have a place in that kind of workflow.

Also, for medium-sized projects and up I've found its planning heuristics some times produce pretty bad plans (in terms of deadlines and resource utilization), and you have to guide it towards a better solution, by adding artificial constraints.

But having a project plan that I can express in the form of tasks and constraints, and that I can fully track using git, makes up for any of TaskJuggler's shortcomings.

I believe that tradeoffs between individual freedom and the common good are necessary. So I am biased in favour of intervening when it's necessary.

But it's very hard to see how these social network interventions are well thought out and have considered all the possible side effects, many of which are mentioned in other comments. I suppose they're tracking the data and will change course if this doesn't work how they expected..

Still, rather than being a case of deplatforming harmful speech, these look like amputations of entire conversations from the service, maybe to take the spotlight off the degenerate nature of Youtube as a human communication platform.

It's clear that the ability of bad characters to screw up an entire system, as you say, is at least partially enabled by Youtube's incentives, and the features those lead to (the old radicalization = engagement fiasco for example). A better way to combat disinformation would be to understand how Youtube often brings the worst out of its viewers, and to fix that. But it's not clear who has the incentive or the obligation to do it.

The alternative is to move the conversation to other types of social networks, with other incentives. But that seems even harder.

What is clear to me is that having most of the world get their news from a service that algorithmically (I think, it's unclear from the article) bans a fully vaccinated, pro-vaccine M.D. for suggesting people who have been infected have immunity (https://news.ycombinator.com/item?id=28693407), to give an example, is not ideal. If they choose to do this instead of tackling the problems in their recommendation system, which rewards disinformation and other harmful types of content in all sorts of topics, not just vaccines, then it's even worse.

The argument is usually that non-linear effects of the size of their network make the potential or actual harm Facebook do much greater than anyone else, therefore it makes sense to focus on them.

Calling them "evil" can be useful to mobilise people, but it clearly makes the conversation a lot less nuanced than it needs to be, and it's unfortunate that people often use that type of language.

This is useful to attackers in social engineering scenarios for sure.

Additionally, some KBA authentication schemes might still be in place which make leaks like this one particularly problematic. Eg. one of my banks still asks relatively easy to answer questions to authenticate me when I call to unlock my card.

The most infamous KBA incident was the large scale IRS's tax returns fraud that occurred in 2014-2015:

- https://krebsonsecurity.com/2015/03/sign-up-at-irs-gov-befor...

- https://krebsonsecurity.com/2015/08/irs-330k-taxpayers-hit-b...

- https://krebsonsecurity.com/2016/02/irs-390k-more-victims-of...

The type of data leaked by the Thai government doesn't look too bad, but one should not underestimate the creativity of attackers, especially when the amount of data is large (and might overlap with other, previous breaches that contain different attributes.)