pro grade kit standards

Which are you referring to? Build quality and repairability? IME, enterprise laptops are well built, but generally have horrible quality displays in terms of both resolution and color gauntlet support.

Fellow senior developer. Initially I was worried about exactly what you’re worried about with juniors. Now I’m also worried that management layers are simply pushing for higher velocity without giving anyone time to think about a problem. We’re in this nasty loop where one person defers more decisions to a LLM to push their individual velocity up. They then get rewarded. Who care if they don’t know how the code works, it works! The tests pass. More people on the team should do the same or else. Then someone takes it a step further.

It will be very interesting to see how maintainable, or not, corporate code will be in a few years. There could well be a booming industry for people to come in and clean up the mess.

That extends beyond just terminal but completely agree that their stock experience is… not great.

Let me assure you this is already happening.

I will give it a try, thanks for the suggestion.

Sorry, I meant a decent editing workflow. Things along the lines of editing - adding outlined text, moving and/or removing things, etc. For example, I’ve tried gimp a few times but I’ve found myself fighting against the way it wants you to do things.

Thanks a lot for the suggestions, I’ll have to check Pinta out.

I found darktable pretty user friendly TBH. The thing I’ve been struggling with is image editing - I can’t find something that has a decent workflow. I’m not looking for anything fancy. Paint.net on windows more than met my needs when I was spending more time in windows.

Straight up vibe coding is a horrible idea, but I’ll happily take tools to reduce mundane tasks.

The project I’m currently working on leans on Temporal for durable execution. We define the activities and workflows in protobufs and utilize codegen for all the boring boiler plate stuff. The project hasa number of http endpoints that are again defined in protos, along with their inputs and outputs. Again, lots of code gen. Is code gen making me less creative or degrading my skills? I don’t think so. It sure makes the output more consistent and reduces the opportunity for errors.

If I engage gen AI during development, which isn’t very often, my prompts are very targeted and the scope is narrow. However, I’ve found that gen AI is great for writing and modifying tests and with a little prompting you can get pretty solid unit test coverage for a verity of different scenarios. In the case of the software I write at work the creativity is in the actual code and the unit tests are often pretty repetitive (happy path, bad input 1…n, no result, mock an error at this step, etc). Once you know how to do that there’s no reason not to offload it IMO.

There’s not a great answer to your question and the ‘right’ choice is going to be situational. The reason to migrate to Rust is simple: fewer possible bugs should reduce maintenance costs. Whether or not migrating functionality between languages makes sense is another can of worms. Is there enough documentation to avoid the nuanced edge cases that are handled by the current solution’s code? Is this a simple port, does it only need interface compatibility, or should a larger area of code be modified? If the code is shared how does the rest of the team feel about the potential language?

I do not know what happened re: drama among Linux maintainers but I seen rumblings about it on Lemmy.

Rust is spiritually fairly close to C/C++, but with modern convenances like memory safety and ease of concurrency. It compiles somewhat slower but it’s compiler errors are more friendly IMO. Rust can be as fast as C++, is also cross platform (eg windows/Linux/Mac) and scales up/down from IoT device level to desktop to seerver applications. If you’re going to be writing a lower level app Rust is a good language to look at, but you can also write GUI applications in Rust too.

Here’s a decent overview

Monochrome just means “a painting, drawing, or photograph in a single hue.” But I think their intent was trying to describe an absolute minimum editor. Think Microsoft paint with the pencil tool but it only draws a single pixel per click.

Their list of things is fairly reasonable and will result in a fairly long main quests arc. Example. Depending on your familiarity with these items, as well as your familiarity with rust, it could keep you busy for a while in a non-throwaway way.

I wonder if part of the reason you’re running into a wall is because you’re asking what could be one of many different questions and haven’t provided many hints to help infer intent.

For example, you could be asking “how do I write a Rust application with a GUI if Rust doesn’t provide out of the box GUI functionality?” In the case you’ll need to use one of the many GUI libraries that are out there. These will let you do screen layout, add buttons, etc.

You might also be asking, “am I going to have to build my own UI elements, like buttons and menus, from scratch?”. The answer to this is no, unless you want some kind of new/novel UI element. For example, I made a checked list box item in C# about 8 years ago. All the GUI libraries will provide mechanisms to declare and position things like menus and buttons. They’ll also provide hooks to let your application know the user did a thing.

Finally, you might be asking about how to actually draw/render the picture portion of your graphics editor. The GUI library you choose will significantly impact this. Example. Example. Example. Note that these may or may not be good choices to use.

I didn’t spend a ton of time digging in, but I think the thing that gets the mainstream handhelds with AMD integrated graphics are the custom drivers. Maybe if a less mainstream device uses less custom components it’ll have better compatibility?

No judgement meant, but without understanding your use case it’s hard to make a good recommendation.

What you asked first: I have an Asus Ally X. I’m truly just like @strayce@Strayce@lemmy.sdf.org in that my purchase choice was influenced by the ability to use it with an eGPU. From what I’ve read, using an AMD eGPU with an Ally X is a recipe for frustration, but Nvidia eGPUs are fine. I never actually pulled the plug as my use case for the device changed after I started using it. It can absolutely be used as a full fledged PC, since it actually is one, and I’ve taken advantage of that a few times.

Musings on my pursuit of a convenient single device solution follow. You’re welcome to stop here. I’m not here to try to convince you of anything, only to share my own struggles. Maybe you’ll even be able to help me with them.

I’ve been chasing the promise of a convenient all-in-one device for a while now. Tablet form factor devices (surface pro, iPad, etc) are good as tablets, but propping them up on your lap with a keyboard is awkward. I’ve found that this limits where you can realistically use them. Sure, you can use a tray/lap table setup, but if you need to haul it around with you it starts to lose convenience. I’ve always fallen back to using these devices as tablets. It seems like using a handheld as a computer replacement would face the same hurdles when you’re away from your desk and add another one: the need for an an external display.

As for why I didn’t buy an eGPU for the Ally X, the most frequent time and place I use the Ally X is on the couch, next to my spouse as they watch TV, after my kids are asleep. I quickly realized I was self-selecting which games I play on it. I’m actively avoiding entire genres like real time strategy, which I personally enjoy a lot, because those games greatly benefit from a mouse/keyboard setup. I want a fast/convenient setup and break down. I don’t want to have to worry about gathering and stashing accessories. There’s also the reality of running on battery and heat dissipation. Keeping the Ally X in 13 watt “silent” mode results in 20 watts of actual power draw, very low fan noise, and ~4 hours of battery life. Its 17 watt “performance” mode is still fairly quiet and lowers battery life to ~3 hours. My spouse finds turbo mode too loud and you’re looking at 1.5 hours of battery life. Noise aside, playing while plugged in diminishes the convenience for me.

Despite a few false starts, I’ve still found myself stuck in the camp of portable device + laptop + desktop - although my desktop sees pretty infrequent use these days.

Like @strayce@lemmy.sdf.org my handheld supports an eGPU and can run bazzite. However it’s another mainstream unit. Personally, I got my handheld to be a hand held to play around the house using its built in screen. The onboard graphics have been more than capable, although I’ll admit that I play slightly older games.

If you’re looking for a less mobile setup and/or are more budget conscious, a used PC is probably going to be way better bang for your buck than a hand held with an eGPU. My gaming PC still packs a (used) 1070ti and shrugs off most games at 1440. Sure, I can’t max graphics in everything but with moderate settings I can still have very solid and stable FPS.

Nope! That’s part of the fun sadly. At least if you’re technical you’ll know that not all type-c cables are the same.

Display port over USB-C is totally a thing. With things like USB-PD USB seem to be getting dangerously close to becoming the standard for everything. The cables are a wreck though and are way too hard for a layperson to tell apart.

deleted by creator

Spot on answer.

While I totally agree with you, it really does seem like we’re moving back towards the era of centralized committing, at least for mainstream computing. More and more “desktop” applications are really electron apps with a good chunk of the compute happening server side. That’s before you start to consider the many browser based word processing products, etc.

Not on a steam deck, but I did buy another PC based handheld.

As a Dad with a somewhat demanding job, I don’t get a lot of time on my gaming PC anymore. Having something that’s not squirreled away in a corner that turns on/off quickly has made it a lot easier game somewhat more casually.

I’m generally happy with the performance of my handled, but there is some tension between most of the steam games I’m trying to play on it and the realities of a hand held.

For example, many games on steam are designed for larger screens. Sure, they’ll render fine on a small screen, but things that were very obvious on a large screen can become harder to spot because the game designers could assume more real estate.

I also find myself gravitating toward games that were either built for a console or PC games that don’t require a lot of keyboard actions. For example, I’m presently playing through the original Borderlands after having last played it on PC quite a while ago. I don’t think I would attempt StarCraft II on my handheld though.