There were a lot of non-Commodore monitors marketed alongside the Amiga. This isn't one of them.

Likely this. Some monitors that would work on the Ami wouldn't work in all it's modes. This did. I had the 1084S which added stereo speakers I think.

And 'boss Nox' in SG-1

(Yes the character probably had a name. No I don't remember it)

Thanks. I hate it.

Instead...

1. Have a shaded zone at the left of the brightness bar (which most people will have auto-managed).
2. If the user drags into this zone auto-brightness is suppressed and the user can select an amount of extra dim.
3. If the user drags out of this zone, and auto-brightness is enabled, allow to take over. Otherwise use the brightness at the users point of release.

No need for a magic setting. Brightness control is all in one place.

Trump's peace promises...

You can't have conflict if only one side survives...

I'd like to think Trump & Co don't think that way.

 

I'd like to.

Can confirm here in New Zealand too. Well into the 80's in the relative mainstream, and even seen up to at least the mid-90's in mail-order catalogues (of general household goods).

For something four seasons in, and never heard of it, it's either not that good or not my wheelhouse.

And of course they'll stop at abortion right...

So really just a subclassification of hybrid (a different path for the hydrocarbon energy source to drive the wheels).

Very rarely I might stand all day, some days I alternate several times a day, most days I'll alternate once or twice.

I have fewer back issues since standing for some of my day but otherwise I doubt it makes much health difference either way.

I have a lot of people coming to my desk for consultation and standing definitely improves this interaction. I feel more alert throughout the day (and just switching between standing and sitting gives a small, brief, burst of energy).

It's open source. If manners are an important feature to you perhaps look into contributing... :)

"I accepted all of the bytes you gave me. I didn't do anything with them, but I accept you gave them to me".

I really must remember to book that appointm - ooh squirrel!

Cargo is doing too many things at once. It’s a build system but also a package manager but also manages dependencies? Idk what to even call it.

Coming from Java where you have no standard tool and two current defacto standards (Maven and Gradle) which do similar things in a less clean or standardised way, I think Cargo is one of the least contentious parts of the Rust experience.

Supposively bad typescript

Correct. Bad Typescript. You haven't provided any of the type information to make this a TypeScript construct (this is just JavaScript)

It should be something like...

interface Person {
    name: string,
    age: number,
}

const person: Person = {
  name: "joe",
  age: 23,
}

And the Rust equivalent being something like

struct Person {
    name: String,
    age: u8,
}

let person = Person {
    name: "joe".to_string(),
    age: 23,
};

i32 i64 i8 f8 f16 f32 instead of a single unified “number” type like in typescript.

Those all have different sizes and capabilities. The lack of these requires the JS JIT compiler to try and guess (and deoptimise when it's wrong).

Even in C you can just write “int” and be done with it so it’s not really a “low level” issue.

No, you can't - https://en.wikipedia.org/wiki/C_data_types

• Similarly, Async code starts to look really ugly and overengineered in rust.
• Having to use #[tokio:main] to make the main function async (which should just be inbuilt functionality, btw tokio adds insane bloat to your program) yet you literally can’t write code without it. Also what’s the point of making the main function async other than 3rd party libraries requiring it?

I agree the Rust Async experience feels a little messy, and the lack of an opinionated default makes even the foothills a steeper climb than we might hope. However given all that it's trying to achieve (in terms of Rust drives for efficiency and safety) I don't have any better ideas right now.

Speaking of bloat, a basic get request in a low level language shouldn’t be 32mb, it’s around 16kb with C and libcurl, despite the C program being more lines of code. Why is it so bloated? This makes using rust for serious embedded systems unfeasible and C a much better option.

I don't know how you're getting to 32MB. A release build of the most basic form of a get request is not that bad.

A simple chatgpt generated one app to get the content of an HTTPS URL, using reqwest and tokio is 4MB. I expect this can be reduced with options.

However yes, the default Rust build (with all of the panic machinery and more) is bigger than C. But Rust doesn't have to be the best choice for every niche, to be an excellent choice for several. With that reasoning your return to TypeScript is equally flawed.

Another major issue I’ve encountered is libraries in Rust, or lack thereof. Every single library in rust is half-baked.

Coming from Java, Rust's young ecosystem is definitely noticeable. It's taking a while for it to grow, to mature, and for clearly dominant frameworks to emerge for various problem-spaces.

Java, like Rust, is not opinionated about the frameworks, but the size and age of the community means that clearly dominating frameworks emerge with huge contributor bases - Rust just isn't quite there yet.

As for “memory safety”, it’s a buzzword. Just use a garbage collector. They’re invulnerable to memory issues unless you write infinite while loop and suitable for 99% of applications.

Again, coming from Java (which has a number of excellent GC implementations), Rust takes this a lot further (an alternative to null, protection against aliasing bugs). While I'm still fundamentally a Java developer, what Rust achieves here is significant.

Then use C or C++ if you really need performance. Both of them are way better designed than Rust. In most cases though it’s just bikeshedding. We’re not in 1997 where we have 10mb of ram to work with, 9/10 times you don’t need to put yourself through hell to save a few megabyes of a bundle size of a web app. There are apps with billions of users that run fine on php. Also, any program you write should be extensively tested before release, so you’d catch those memory errors if you aren’t being lazy and shipping broken software to the public. So literally, what is the point of Rust?

Tell me you don't pay to run anything large on cloud infrastructure without telling you don't pay to run anything large on cloud infrastructure. There's a cost to CPU and RAM. Java does okay on the first, but has a long history of doing poorly on the second (c'mon Valhalla - a Java enhancement project that will help here).

Who cares? Coding is a tool to get shit done and I think devs forget this way too often, like if one works easier than the other why does learning lower level stuff matter? It’s useless knowledge unless you specifically go into a field where you need lower level coding. Typescript is easy, rust is not. Typescript is therefore better at making things quick, the resourse usage doesn’t matter to 99% of people and the apps look good and function good.

Of your post, this is very nearly the only part I can somewhat agree with. Our industry primarily has more of a need for 'solution now please' than 'optimal solution later'. Engineering time matters. The learning curve and cycle time of Rust are barriers.

Also, while Rust is a very safe language to refactor in, it's not quick to refactor in. The less ceremony and strictness there is, the easier it is to experiment and then refactor. This is, in part, why I think Python does so well in the ML/Data-science space - that niche is more R than D in the R&D balance of software development.

So again, Rust suits some development needs better than others, now. However as it matures I think we will see it grab little pieces of the niches previously occupied by other languages. As it's tools and libraries get better, and as the pool of familiar developers increases, Rust's strength are going to translate more easily into dollars without costing time.

 

I'm not ready to switch to Rust fully. But neither am I putting it aside - and I look forward to its continued improvements in libraries, language, tooling and adoption in more and more places.

(I can say that I'm not planning on using TypeScript for any more than our front-end development though)

Again.

The article seems to only talk about an advance in knowledge about the degradation process. I see no mention that they have a proposed solution.

Other than the fact the article contains an out-of-context quote, where does the "smaller, lighter, and cheaper" come from.

Great there's new knowledge but seems a little more jumped-the-gunny than usual for battery-tech improvement claims.

Oh no!

Anyway...

(Apparently I'm too antisocial for FB)

Don't know... Don't care that much... But I had one and it was awesome.

Sheepdog trials. Though mostly it's about making things go through the gates.

I used the hell out of FidoNet back in the day.