My custom XFWM theme has square corners on windows without focus and large-radius rounded corners on the one window with focus.
The square corners are part of a 2 pixel wide border (one black, one white) because who needs to waste space on handling things we aren't manipulating? But the title bar is high-contrast, because you'll go looking for it when you want to switch windows.
The round corners go with a fairly thick border in a customizable color, usually something very bright in the yellow, orange or cyan ranges. When you sit down, you should immediately know what is active.
- the original Motorola StarTac "Star Trek Communicator" flip.
- the Danger Hiptop / Sidekick II rotating screen-over-keyboard
- the Motorola Droid slide-out keyboard
- the OnePlus 7Pro slide-out selfie-cam
Only that last one was motorized, but mine is still working. Holes and divots and islands and any other kind of screen interference is strictly inferior.
I liked the slide down mechanism of the nokia 7110 also. Bonus points for the microphone being at the bottom of it so it served a purpose by putting the mic really close to the mouth (unlike later sliders like the banana phone which didn't do this)
The front camera was hidden and you would slide the back up to expose it. Was not motorized and functioned using magnets. Very similar to what old dumb phones used. Super reliable and easy to use.
Yes, that's a good point too, I never ended up buying any of my audiophile stuff from Drop because the stuff I was interested in was usually available with faster shipping from Amazon for either the same price or only a slight price increase.
The retailer's problem can be solved through diversification. If you sell enough different things, and they are all of good quality, people will come back to shop for other things that you sell.
The manufacturer's problem needs more capital, because it is also solved through diversification. If the total market for space oscillators is 120,000 a year, with about a 2-3% annual growth, making the best space oscillators has a cap. You'll need to figure out how to turn your expertise in space oscillators into neighboring products - space modulators and electromagnetic oscillators, perhaps - each of which is an R&D investment itself.
Massdrop's original version is essentially what you are describing, they were a middleman that ran drops where you would pay for something upfront and once done they would collect the money and order it from the manufacturer before shipping it to you in a couple months. They used to sell a wide variety of things, but over time they moved more and more to their collaborations and Drop branded goods in the headphone and keyboard spaces and essentially became just another online retailer.
> The retailer's problem can be solved through diversification.
Perhaps in a textbook economy, yes; but in the U.S. economy that Massdrop operated in, continued sales of products hinged upon wages being available to spend on optional desires. That economics assumption has not held: most people’s inflation-adjusted pay decreased over Massdrop’s lifetime while the inflation-adjusted costs of necessary goods increased (thanks, enshittification and shrinkflation!), and so their potential customer pool would have been steadily draining throughout their operating years. The private equity model of ‘diversify to generate horizontal revenue’ only functions in a wages-dropping economy for retailers selling necessary goods, such as Walmart; for Massdrop, whose goods are exclusively non-essential, they had little chance to survive by increasing product diversity. (And effectively none whatsoever, considering how small their niche was to begin with!)
> "I haven't heard any customers request this." "We can't use Python for that, it's too slow." "That introduces too much complexity." "We tried something like that before and it didn't work." "DevOps won't want to support another service." "People are used to the way it works now."
> None of these people are wrong or stupid. And none of them have added any value.
Bzzt. Since all of these people are correct and smart, it is now your job to have great answers to their objections.
No customers requested this? Prove that there is a market that wants it.
Can't use Python because it's too slow? Show a proof of concept that is fast.
Too much complexity? Demonstrate that it's the minimum amount of complexity to achieve all the requirements.
Tried it before unsuccessfully? Explain what's changed since then.
DevOps won't want to support it? Burn down the company and start again: you've managed to undo everything that the word "DevOps" is supposed to convey.
People don't want change? Nah, people like change when it is obvious to them that the change is good. People don't want bad changes, and their justifiable default assumption is that a new change is a bad change. You'll need to overcome that.
And if you can't convince these acknowledged correct-and-smart naysayers, then be glad you didn't chase that rabbit. Come up with a new idea tomorrow.
There is value in critically evaluating ideas and possible endeavors. On the other hand, demanding an answer to every little pocket of uncertainty creates a huge burden that prevents exploration. It's one thing to be exhaustive in the criticism by examining individual scenarios, evaluating cost benefit in a measurable way, etc. That doesn't seem to be what the author is describing. He's describing critical & low effort cheap shots.
The examples he used included: the plan depends on a different team providing labour and that team is not on board, the business plan for the idea does not make sense.
I suppose they are low effort in the sense that they are very basic 101 criticisms, but i wouldn't call them cheap shots.
Literally no plan is ever going to work if it involves the labour of others without their (or their supperiors) consent. It seems to me a very valid criticism to make. That doesn't mean its the end of the idea, it means you need to have a plan to either get the other stakeholders on board, or a plan to do it without them.
It's not a plan, it's an idea. You're shooting down an idea for not being a plan. The best person for coming up with the idea will probably also come up with some of the pieces of the plan, but they're unlikely to be the best person to figure out all of it. That's why you have a company not a sole proprietorship.
The problem with this is, that the article literally says:
> The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.
If they did that much upfront work, it's more than an idea. And if it's that easily shot down, they should have done even more upfront work and probably slowly gotten others involved.
Honestly, it sounds like someone so desperate for credit, so worried that someone will steal the idea, that they feel compelled to unveil it in a large gathering that was convened for some other purpose. And that never goes well.
Ideas truly are a dime a dozen. If one gets shot down, then you can reflect whether that was warranted, and try again with the same idea if not.
If you're really emotionally invested in it, as the guy writing the article seems to be, then you damn well better have more than just an idea, and you should understand enough about human nature to slowly try to bring individuals onboard to help before you put it out in front of a big crowd.
> You're shooting down an idea for not being a plan.
If you are pitching an idea out of nowhere, than i think it better have a semblence of a plan, otherwise you are just wasting everyone's time.
Like maybe its a bit different if you are brainstorming for an acknowledged problem, but that is not what the article made it sound like.
The article made it sound like the idea was being pitched unsolicited, with no clear problem it was trying to solve and no clear plan on how to do it. After all 2 of the so-called cheap criticisms were people asking why we want to do this ("the customers aren't asking for it") and how are we going to do it when it has dependencies on stakeholders who have not bought in ("devops doesnt like it").
Why would anyone care about such an idea? Like if you want to work on something by yourself, you dont have to convince anyone, but if you want other people on board, you are going to have to answer basic questions. Questions like: what benefit would implementing this idea bring me, and will my effort on this idea be a waste because neccesary stakeholders aren't on board.
There are a lot of details that can be sorted out on the way. Things like, why would we even want to do this in the first place, is not one of them.
And shooting down shit is also valuable. It is fine to have ideas without thinking them through, and it is also fine to criticize those ideas without thinking through the criticism. That is how we figure out how the ideas could work.
No one should care about devops’s consent when they’re given a work item that comes from someone higher up on the org chart. Their consent is willful employment. Similarly, no one should care about an engineer’s consent when given a work item in a similar context.
If the engineer proposes an implementation the devops team doesn’t like, the devops team should come up with a counter proposal that still fulfills their requirements. And if their counter proposal fulfills the requirements but the engineer objects, then whoever’s at the top of both their branches in the org chart should be making the decision.
These are all risks. Not all risks need to be mitigated, but some can be. Others can be accepted. Saying “Python is too slow for production scale, but our goal is a small proof of concept,” is a valid answer even if it doesn’t “solve” the complaint. And if you don’t even have that answer, then the burden is not your problem. The lack of due diligence is.
These are the table stakes of uncertainty, not delving into every little pocket. If the language and ops are under question, this sounds like an entire new project or significant extension. The bit of time it takes to answer all those questions is worth it.
You can fire the shot and then patch the hole at the same time, proposing solutions to the same problem you pointed out, rather than just shooting and letting one person handle defense from every attack.
By proceeding with things that will gather more data—such as prototyping, or further independent research—vs spinning indefinitely on "hypothetical" discussion-only shots.
How do you know if it survives the shot without that, if it's just person A saying "I don't think Python perf will be an issue" and person B saying "I think it will"?
> How do you know if it survives the shot without that, if it's just person A saying "I don't think Python perf will be an issue" and person B saying "I think it will"?
That is the point, knowing that it is a point we want to test is valuable. If person B there didn't say he thought it would be an issue you probably wouldn't have tested it, it was valuable for him to say that.
>Ideas need time to be explored, and given a chance.
sure, and the time for that is before you bring them to potential critics.
unless a meeting is intended as a brainstorming session where any thought, no matter how unformed, is welcome, meetings are not a time to present your initial unexplored thoughts to colleagues, bosses, or other departments. take a couple days, think about it without spending other people's time, try to imagine people's objections and have answers to them. then present. shouting things out in a meeting before you've considered and come up with answers to the most obvious counter-arguments is just a time-waster.
You must have very different kinds of meetings than I do. Unless you're going into that meeting with a rehearsed PowerPoint presentation, or there's a strict agenda that doesn't allow any time for exploration, I expect to hear imperfect-ideas-in-infancy. One of the reasons we have meetings is to allow collaboration to happen. It's a format for working together.
Yes, meetings vary profoundly in terms of their quality, purpose, and participation. For instance, is it a meeting of peers, or are managers in the room? If there's a large disparity of roles in attendance (e.g., junior engineers, marketing managers, and maybe one or two executives), it's different than if it's a true meeting of peers. And if managers are capable of attending those meetings without quashing collaboration, hats off to them.
Really depends on the context I think, brainstorming session? Naysaying does have a habbit of stunting an idea's growth in the session. Sometimes you need to imagine you've solved a bunch of hard problems before you can explore the value the idea has.
I say this as a semi-reformed naysayer. I am critical of implementation plans, but let ideas breath a bit in a more exploratory setting before I start bringing up constraints.
If the proof of concept takes an hour to code up, or proving the market exists just takes a bit of googling, then sure, you can prepare that before the first meeting where you suggest the idea.
If the proof of concept requires spending a few days in the machine shop making jigs and parts, purchasing equipment, and a custom PCB, then I really hope you'll bring it up for discussion beforehand in a meeting. Ten minutes of discussion with colleagues might be as useful as several iterations of prototyping. Not so that they'll shoot it down, but because someone might say "oh yeah, we have a spare mcguffin from last year's demo that you can use, should save you lots of time."
>DevOps won't want to support it? Burn down the company
Still true but you seem to blame the ops. I've been in a job where every dept was allowed free for all tech budgets. They would hire incompetent consultants to dump 3000hrs of work on devops then do it again next week and complain about how devops never gets anything done. Then 5 other departments would do the same thing.
You know how 99% of the work is in that last 5% of the project. Thats how all those consultants would leave everything.
I read that as a frustration with the disparity between "you build it, you run it" and the enterprise-y habit to co-opt terms from free-roaming developers and stripping them of all meaning.
You can still have a central team of operators. When they're expected to deploy and support applications from development or procurement teams, I'd argue that's something else than devops for better or worse.
what I meant with "DevOps won't want to support it" was someone saying this before DevOps had even been asked, and by someone who wasn't even on DevOps, who just assumed that they probably wouldn't like this sort of thing.
If this meeting doesn't include devs, I don't know what the context of anything in the article is supposed to be about. There are no major new ideas in business that don't involve software.
If it is not the case that "devs" is not functionally equivalent to saying "DevOps", then "DevOps" doesn't exist. You have an operations group, and you need their buy-in, so they should be invited to the meeting.
That all sounds fine if they're not the kind of naysayers that will just let the company collapse around them rather than risk putting one of their own ideas out there on the chopping block. All too often nothing is the worst thing we can do, and there are a lot of professional do-nothings out there.
you're right that a good idea should be able to survive scrutiny. The issue I'm describing isn't "someone asked a tough question". It's when objections pile up so ast that nothing can survive long enough to be properly evaluated. That's not a rigorous process, that's just a kill zone. The difference between a productive and unproductive kill zone comes down to culture. Teams that default to "here's why it won't work" end up very efficient at producing nothing. The teams I've seen do this well still kill ideas but they just do it after giving them a fair shot. The proposer has to do their homework but the environment has to let them get far enough to do it.
> People don't want change? Nah, people like change when it is obvious to them that the change is good.
I agree with more or less everything but this one.
I would modify it.
People don't want change? Nah, people like change when it is obvious to them that the change is good for them personally.
You can introduce a change that would be great for the organization and customers, but totally eliminate the current project a team has been working on unsuccessfully for years. You will be shot down no matter how good your idea is. And many times, there is no way to turn it into a "win" for the team that you need to win over to your side due to politics.
So shooting down ideas - for that team - is indeed a skill. A self-preservation skill. I've seen teams able to employ this skill for nearly a decade where it was obvious to any outside observer there were numerous ideas that would eliminate their need to exist altogether.
the "good for them personally" reaction is so true. It's almost like a team-level version of the inonvator's dilemma, where protecting the thing you already own feels more rational than supporting something that might replace it.
> Bzzt. Since all of these people are correct and smart, it is now your job to have great answers to their objections.
Power assymetry and tenure are a factor. So is "culture eats strategy for breakfast" realities in organizations.
e.g. Change of pandemic messaging in early 2020 from "covid transmits by droplets and fomites and 2 meters and handwashing keep you safe" to "covid is airborne and fills a room like smoke" (and multiple mitigations around that) was attempted in groups by multiple expert scientists and ultimately took years when it needed to be done fast. One key moment: https://www.google.com/search?q=%22where+is+your+evidence+li... You can come with evidence for those tough questions to support your position, but one grandee scoffs at your suggestion in the meeting you networked hard to get and there's no recovery.
> Can't use Python because it's too slow? Show a proof of concept that is fast.
Python is slow though, and for many use cases it won't work.
For example, say somebody wanted to build a performant systems type software like version control. You're not really going to do that in Python. Something like that would even be slow in much "faster" Node.js.
Some stuff you can't really use dynamic langauges for, if you want it to be performant. Low-level stuff usually, of course.
To your point, you could showcase how Python might call out to other languages like Rust, and show why it's convenient to keep some stuff in Python.
> For example, say somebody wanted to build a performant systems type software like version control. You're not really going to do that in Python.
Actually, bazaar [0] (now breezy [1]) was a distributed version control system written in Python. It gained some non-Python bits over time, but iirc it was originally all Python.
As a (spiritual) successor to Tom Lord’s Arch [2] it was the second DVCS I used and, while slower than git, was performant enough for my needs at the time I used it.
Most distributed version control is IO bound, and Python isn’t terrible at that.
Mercurial was written entirely in Python for quite a while.
But more to the point, I doubt there are many ideas for which the choice of implementation language is core to the idea. Maybe that's how it was presented, but that's usually because you need a concrete realization of an idea in order for people to even get what you're talking about.
Lol, Mercurial is written in Python (and now some Rust).
Most of the time, when someone raises a hypothetical performance criticism, it is either to further their pet language or as a cheap shot to shoot something down.
I don't care about my job anymore, that's the problem. One too many good ideas has been shot down, one too many stupid ideas has been pushed through. If my manager and a huge chunk of my coworkers are simply incompetent, then trying to convince people to do something smart gets old very fast.
> People don't want change? Nah, people like change when it is obvious to them that the change is good.
I agree with some of what you said, but just want to point out that you're doing the very thing you criticise here.
I think lots of people genuinely don't want change. Hopefully you have great answers to my objection.
In general, I've found the question of "who needs to provide evidence first?" is one of the most casually ignored and maliciously manipulated questions in so much professional discourse. The answer is often implicitly "the person with less role power" which by itself is a terrible answer.
Nobody sensible runs the latest kernel; nobody running PG in production should be afraid of setting a non-default at either boot time or as a sysctl. So this will, most likely, be another step in building a PG database server (turn off pre-emption if your kernel is 7.0 or later and PG is pre-whatever-version).
At worst it might become a permanent part of building a PG server and a FAQ... but if it affects one thing this badly, it will affect others.
From the article: "Linux 7.0 stable is due out in about two weeks. This is also the kernel version powering Ubuntu 26.04 LTS to be released later in April."
Unfortunately, lots of people will be running it in less than a month. At the moment, it'll take a kernel patch (not a sysctl) to undo this-- hopefully something changes.
Not nobody but not everybody upgrades to the newest distros immediately. That's the advantage of LTS. I've even found that a lot of programs have poorer support on 24.04 than 22.04 due to security changes, so I'm fine sticking with 22.04 as my main dev system.
> ... not everybody upgrades to the newest distros immediately.
While that's true, for new deployments the story is often "deploy on the latest release of things available at the time".
So, there will probably be a substantial deployment of new projects / testing projects using the Linux 7.0 kernel along with the latest available software packages in a few weeks.
I would argue it's mainly inexperienced devs who deploy on the very latest. Once you get some more years under your belt you realize the value of LTS versions, even if you don't get the shiniest shiny.
Yes it’s LTS but the point is that the LTS system has overlapping support so you can wait on an older LTS for a bit before upgrading to a newer one. And it’s somewhat prudent to do so if you value stability highly, because often a few new issues will be discovered and patched after LTS goes live for a bit.
This seems to be brushing off a major performance regression just because you personally don’t upgrade for 4 years. I don’t think that’s common at all.
Someone said "its fine nobody uses this" and someone else gave the world's biggest slam dunk of "Ubuntu in 1 month" and your reply is that "not everyone does it". How far from the point can you be!
In the Linux world this is the worst possible scenario, distro with the largest adoption, LTS.
Not trying to downplay the importance of this, but the LTS versions aren't until the first point release, so 26.04.1 (typically six months or so after the release).
I can't find any link, so I think I'm getting mixed up between what they consider LTS and when the upgrade tool starts prompting to upgrade. If you're on the 24.04 LTS, then you don't get prompted to upgrade until 26.04.1
I think most people on enterprise-y systems wait for (at least) 26.04.1, the window is 3 years (when on 24.04, which is supported until ~2029-04-30, it's 1 year when on 22.04) starting now, hardly anyone switches immediately.
> [...] used huge_pages=on - as that is the only sane thing to do with 10s to 100s of GB of shared memory [...] if I disable huge pages, I actually can reproduce the contention [...]
if your kernel has CONFIG_PREEMPT_DYNAMIC then you can go back to the pre 7.0 default by adding preempt=none to your grub config. I haven't seen any plans by Ubuntu to drop CONFIG_PREEMPT_DYNAMIC from the default kernel config.
actually i just checked, yeah, ubuntu would have to add none back to the kernel and `CONFIG_PREEMPT_NONE=y` the config so that it can be selected at boot.
That's the big thing - PSQL will be tested, noticed, and fixed (and likely have a version that handles 7.0 by the time it's in common use).
But other software won't and may not even be noticed, except as a (I hate using the term) enshittification.
Better to introduce the "correct way" in 7.0 but not regress the old (translate the "correct" into the old if necessary) - and then in 8.0 or some future release implement the regression.
Exactly, this is how it’s usually done. As the developer on the mailing list mentions, implementing a new low level construct in 7.0 and a performance regression that requires said new low level construct to mitigate is not great. You need a grace period in which both old and new approach is fast.
I don't think anyone will listen to this for the pleasure of listening to music.
AI crap can be much more listenable-as-music but nobody likes the process or the product.
reply