sigy

I once to believed this too. And then I got much more skilled at prompting agents to get the results I wanted.

As someone who is and always has been a very unapologetic skeptic, I am still surprised by the number of capable people who can't accept that things are changing.

It can't be either none of it matters, or all of it matters. The truth lies in the middle somewhere.

I was excited to see this, since I'm looking for a symbolic algebra library.

But then I saw the absolutely awful license. A license like that at a time like this is no small miscalculation.

I disagree with this take. Particularly because this isn't just a little more of this or that. It's a well-integrated set of features that should have already been on the market in some form, but wasn't really. And it's also a premium setup in terms of each feature individually. It really does feel like the whole is more than the sum of its parts in practical terms.

I don't feel FOMO. I'm thinking more "why did it take this long?"

I ordered this within 30 minutes of learning about it. I've been waiting for something like this. Here's why:

- My eyes are getting older, and I need a better visual connection to my work.

- We spend much of our lives in front of these devices. Optimizing this just makes sense.

- It is more than just a monitor with some features. It's a well-rounded kit with good software support.

- I previously used multiple 4K monitors and external KVMs. The built-in KVM and management software that works with the display makes multi-system use as easy as it could possibly be.

- The resolution has _more than_ overcome the issues I had with font rendering on lower resolutions while trying to have more visual workspace.

- The thunderbolt hub has vastly reduced multi-system USB/wiring/speed clutter and confusion.

Yes, it was expensive. Yes, I'm very happy with it. Within this week, it has drastically improved my sense of comfort and utility, and I got rid of all the other monitors.

Ok, for the gripes:

- The curvature is a bit minor compared to what I'm used to. Given the spatial density I want, the optimal distance is less than 30" from the display, and with my aging eyes at this distance, looking from center to edge changes my focal depth by more than a small amount. That said, the off-axis views are quite good. Essentially, looking at this display from a longer distance wastes much of the effective ocular resolution.

- The software is great, but if you want something more tactile, reaching to the sole multi-purpose menu stick is not that great. It wouldn't have hurt for them to provide a USB-connected desktop switch. I hope they still do. This monitor runs its own "OS" of sorts, and can be extended with new functionality should they choose to.

- Finding the improved dynamic range took a bit of learning. The way it works feels better (less of a special case) for me, but I had to go adjust the settings to tap into higher resolution per color plane.

If anybody has any specific questions, I'll be happy to answer them.

This advice is not better than random. It is actually much much worse. It is a pseudo-formalization of a chilling effect.

Actively preventing people from sharing their ideas or being exposed to different points of view is one of the ways that despots stay in power. Don't be part of the problem. The first amendment was the first one for a reason.

Profit margins on eurorack are pretty damn low. And you need a lot of knobs and jacks and plugs. Even a hall effect sensor may be out of the sweet spot for cost.

The physical interface is an intrinsic part of the design of any eurorack module, including artistic elements. If you actually use these, then you quickly tire of menu diving for simple options, and only modules that do very particular things make it worth the bother. For everything else, the layout must be accessible, memorable, understandable, and not too crowded. And it helps if the visual of the thing conjures up memories of how it sounds or what it does.

I host OSS images there, and I see no notice about how they will be affected. If they limit access to my published images, then it will be an issue. In that case the benefit and thus incentive for many of the projects which have made docker and docker hub pervasive goes away. Without that adoption, there would probably be no docker hub today.

This should help people understand a bit better why this feel a bit underhanded. The images are free, and I and many other OSS devs have used docker hub in partnership to provide access to software, often paying for the ability to publish there. In this case, any burden of extra cost was on the producer side.

Turning this into a way to "know" every user and extract some value from them is their prerogative, but it does not feel like it is good faith. It also feels a bit creepy in the sense of "the user is the product".

This essay might win an award for having the most words for the simplest point made. The genuflecting and synthesized history lesson that it's the first 3/4 of it was an entirely unnecessary diversion.

There is and always will be those who take earnest and reasonable ways of describing beliefs and behaviors and turn them into hyperbolic ad-hominem at both ends of the spectrum. If we are aware of it, and use common sense and a little bit of critical thinking, there will be less of this.

Did that take pages of text? No.

I was curious about this as perhaps a new approach to recipe-oriented bytecode injection. But the I looked at the project's (long) history and docs status. It seems that the main contributor has tapered off this project over time, and more specifically hasn't been active since July. (Mumfrey, if you're out there, please tell us what's up)

So, OP, what made you mention this here now?

I was paid to do code analysis on medical systems coming up to Y2K. Yes, there were Y2K related bugs which would have munged patient data, including exam data and results. Yes, we analyzed every point in the code having anything to do with dates and fixed the issue. Yes, this needed to be done to avoid injury to people. It was a months long effort due to the size of the code base.

I went to see the film tonight. I went into the theater not knowing what to expect, but keeping an open mind since this was a "Kyle" film. Meh. It's goofy, mildly entertaining, and well, just like a film from before Y2K. But I somehow managed to enjoy it.

I should have been more specific. I meant lopsided as in the character of the two candidates. I posit that any decent, moderately educated citizen should be able to see this clearly, but therein lies the issue.

I find the overall assertion to be grasping at a counterpoint. Particularly, 1. The reference to "Medieval" labeling goes all the way back to the beginning when D&D overall was nothing but a seed and an experiment. Modern materials do not come with the same presumptive labeling. 2. There is good reason to not include all the trappings of life in any particular era, as the core of D&D is a set of rules, and all the settings are simply versions of content that work on top of it. There are many such settings and they decidedly do not come from the same time and place. 3. Many of the arguments take the form of "It's not ..." wherein the thing that is not explicitly medieval is also not explicitly not-medieval. For example, it's easy to consider the texture of towns and villages as we generally see them in D&D as operating within the tapestry of an explicitly medieval (as the author describes) environment, or within any variation thereof as desired by the DM. Similarly you could also say "D&D does not explain how to make ice cream accurately." It was never _seriously_ about being medieval nor seriously about making ice cream.

Yes

EMF becomes a fungible energy medium. Imagine storing energy in a field, just as we do with MRI machines, momentarily in the poles of motor windings, essentially anything inductive, or that operates as an electromagnet. Apart from dielectric losses and other environmental factors that are inescapable, the magnetic field becomes elastic like air [in] a balloon. The potential for this to modify energy consumption patterns is mind-boggling.

[edit: typo]

This should surpise no one.

I'm sincerely confused as to whether this post is satire or not.

It seems that open sourcing it while it is growing up actually makes more sense. If you want community involvement, ideas, testing, contributions, and so on, then hiding the project source is antithetical to why most people participate in open source in the first place.

Open source can mean more than just a license. It should mean more than just gifting a code base once you think you're done.

I don't mean to come across as bitter or entitled. I just question the value of waiting till the last minute. For now, the promise only stands as a way to pull people into the fold. I've seen this kind of promise many times before in projects much like this.

Finally, something to give scientific discoveries back to the people that bought them.

The devaluing of teachers, public education and critical thinking has gone hand in hand with companies using these discoveries as publicly funded subsidies, turning their profits against those who made them possible in the first place.

I'm quite surprised by this request, given that Kotlin doesn't really improve on classic Java language problems to a quantifiably better degree than later JLS improvements. Further, Kotlin seems to bring along its own design baggage from the very beginning which makes it little more than a distraction for most users I've seen try to pick it up.

The divers can not inflate it further once submerged, yet have put their mouths on the container.

Even as a "re-breathing" container, having that reserve of air volume would allow for extended lingering time below the surface, as it would take much longer for the CO2 saturation to become a problem than just a lung full of air.

Thus, this likely served two purposes. 1) buoyancy to counter the weight of armor, and 2) additional time underwater by rebreathing (more) stale air than one can hold in their lungs.

Think about it, what would you do?

I will just change distros if Ubuntu doesn't start making snap an opt-in.

I like the intro style of the article, but also found some that it glossed over things a bit and added some leading assumptions as a given. "goodput" is not helpfully distinguished here, and also explained in a way that is contrary to convention.

Throughput is throughput. Goodput is different.

When I click on the brain muscle, it doesn't show me anything. I really hope you add support for this! It would be a fun easter egg.

I want to second the request to learn more about your workflow. I shepherd OSS projects in addition to dev work, and striking a balance between outreach, admin, and getting things done is always a challenge.

I had the same impression. The only other alternative possibility I could come up with was that the author was willingly playing in meta irony, or that they were someone who feels extremely specialized in something and must cast aspersions at those who are not.

My counterpoint to this article would simply be:

Beware of opinions of self-selecting experts, especially those with a chip on their shoulder.

As mentioned above in the discussion, you do really need specialists and generalists working together to solve the hardest problems. The specialists deserve no more credit for progress than the systems thinkers who choose to operate at the macro level and understand full well why this is essential.

I find the article quite presumptive in the sense that it presumes everyone has the same definition for "gold plated", etc. That, coupled with the With the remedy of "give the guy something else to do" makes me think that the writer is on the opposite of the spectrum which could be characterized as "throw stuff at the wall and see what sticks."

I know this seems pejorative on some level, but I'm trying to paint a contrast here between sensibilities. I think it is worth considering that one person's urgent and long-needed reduction in technical debt is another person's over-engineered. It often comes down to whether the person passing judgement has the awareness of how everything fits together and thus can benefit from a structural tune-up. It could also depend on how many systems and code bases they have had to maintain.

I mean, on balance, we have a really bad track record as an industry of building unmaintainable code bases. Most developers are working on the things they find enjoyable with less regard for making it work well for other developers. I think that the author's remedy of splitting these responsibilities out into separate roles is an indicator of the overall problem. It shouldn't have to be framed in that way to make it palatable to the average developer.

As a developer, you should always want to make the code you work on work well for others, and that includes refactoring on occasion. If you find yourself in a posture where you are always "innovating the new fun stuff" while others are seemingly dragging you down with making it actually manageable, it's time to slow down enough to realize what this means to your team.

By not taking care of your own code so that your other developers find it manageable, you've turned them into your cleanup crew. You need to thank them for being "That coworker" who you find "gold plater, or unproductive, or slow", and perhaps stop building prototypes and calling them done.

Just some food for thought.

The results seem pretty drastic in comparison. Did you drop caches between these measurements?

I hope so too. Émilie's work has been my primary inspiration in learning more about digital signal processing. The Mutable Instruments body of work is a tremendous gift. Thank you so much, Émilie!

Agreed. Their site looks like an ad masquerading as a tech blog.