softfalcon

Except for a large part of Europe, the relative humidity is quite high. So, they're suffering more than most. I say this as someone who once lived in a desert and is well accustomed to 40-50 C summers.

Yeah, that's also a very good point. I imagine they're going to need to support that use case indefinitely. Hence their edge/IoT line of managed switches.

I agree with you that you can't rely on hydro alone to power your country. It also seems like you're trying to be reasonable and suggest that any new nuclear production in your country needs to be done as ethically and environmentally friendly as possible.

Your statement about "We can't be buying France's nuclear energy all the time" really stood out to me.

Are Swiss folks maybe acting a bit NIMBY by not allowing nuclear in their own country, but are fine with buying French nuclear power? It seems a tad hypocritical to be against nuclear, while simultaneously using it as long as it's "not in my country".

I tend to agree with you.

In my opinion, as long as the majority of their profits come from people continuing to buy the self-host devices, it is fairly unlikely they'll ever stop offering those devices. Why change a working business model?

Yes, subscription models are enticing for that recurring revenue... number must go up, right? /s

If a majority of your sales are not in subscription products though, I think it would be foolish for a business to blow off its own leg trying to chase that particular dragon.

Then again... businesses have made dumber calls in the past out of nowhere...

I have heard others say the same as you about Ubiquiti devices. I genuinely curious what bottlenecks you've hit.

I've only been using Ubiquiti as a pro-sumer, but it has held up well for my use case of Plex and little game servers.

I use a Synology NAS for my storage though, which is a slightly beefier mobile AMD chipset.

I'd be very interested to know what I should and shouldn't expect from my ARM based network stack though!

I’m confused. Docker Desktop isn’t supported on Linux?

I just followed Docker’s docs [0] to get Docker Desktop installed on Ubuntu.

Maybe I’m missing some specific point you’re making about some lower level detail, but they support and have instructions for Docker Desktop on Linux in their own docs.

[0] https://docs.docker.com/desktop/setup/install/linux/

Yes, this is correct. When you put the CD into a regular player, a strikingly beautiful (but monotonous) woman’s voice would say:

“This CD is made for the Turbografx game system. Please place it into the CD drive on your Turbografx to play.”

My brother and I thought this was really cool when we were kids. We thought the CD player must “know” that it’s a game.

Still own multiple TG-16’s. The CD-ROM attachment plus Ys: Book I & II was a modern technical marvel at the time.

Hearing full hi-fi stereo anime rock and roll instead of chip tunes blew my mind back in the day.

As someone who owns a SNES and a TG-16, I think I disagree. The TG-16 graphics really pop compared to the SNES.

The SNES can only render 256 simultaneous colours. The TG-16 could do twice that at 512. Its video processor was also full 16-bit.

I’m not sure where you’re getting that the video was the weakness of the TG-16. At the time, that was the Turbografx’s whole claim to fame in that it was superior graphically to the SNES.

Source: Old enough to remember the commercials and bought both consoles to compare like nerds did back then

I keep hearing about natural gas and on-site power for these data centres. I'll believe it when I see it.

There are already have a couple in Calgary and they're hooked directly to the grid. The cost of electricity for the city shot up at the same time. Also, there have been a few brownouts caused by them not being ready to handle late night draws from those data centres.

That's at least what I'm seeing. Though, admittedly, it's from older project articles. Maybe something has changed in recent months?

https://www.cbc.ca/news/canada/calgary/ai-data-centre-albert...

The data coming from the University of Calgary about the data centres they're building in Alberta, Canada seems to indicate that they're using evaporative cooling, which is very expensive water wise.

The bigger concern though, is the power requirements. Which are set to double or triple the energy use of the entire Province (analogous to a State in the US).

https://ucalgary.ca/sustainability/mobilizing-alberta/climat...

This... so much this.

too many SKUs and models - it takes a paragraph to figure out how 2 Dell laptops from the same release year differ.

And yet, I just watched a YouTube video where a "PC guy" was like, "adding the Neo just completely confuses the Apple product line. Are we heading towards having too many Apple options that confuse the buyer here?"

I get it, other than price, the Neo and Air are a bit confusing product wise. Have they looked at how Asus, Lenovo, and Dell are doing their products though? It's absolutely wild the disparity between PC and Apple for laptops.

I run both PC's and Mac devices in our house, we use what fills the job. Recommending PC laptops for family members feels like a total crapshoot though. Every time, I do all I can to find the right device for their needs and there are just so many trade-offs. Maybe I get all the right specs, ensure it doesn't thermal throttle, keyboard/trackpad are A-OK... but the webcam is trash. Ooof... now Mom is complaining about how no one can see her properly at bridge club call.

I brought up how the Neo might do to the PC industry what the Air did to Ultrabooks back in the day. The amount of hate I got on YouTube/Verge with copy-paste, "hahaha, wut, with 8 GB of RAM? lmao, lol, you Apple bot?!" was expected, but also disappointing. There is clearly a market segment happy to continue to put up with the mess that Dell/Lenovo are selling (anything but a Mac).

Wild how tribal we are to our corporate computer overlords.

The era where something like Framework with its fully customizable, repairable, modular laptops becomes the standard can't come soon enough.

For the time being, I'll let Apple/PC continue to duke it out. Hope some competition helps in the long run. :shrug:

Are you absolutely sure they don't want us to add the capacity for them with a pathway for further government subsidies?

Almost everything in tech has been subsidized in one way or another via tax avoidance schemes or outright lobbying and manipulation of the market.

Why would this be any different?

I'd expect something more like a callback where you would specify how your input gets written to a buffer

Yes, and this is the way it works JS currently.

The reason I'm commenting is because it appeared folks were advocating to stop doing this (despite the fact it seems to work just fine).

So... have we now confirmed that the only thing preventing us from running macOS off our iPhones is a software limitation?

(I'm being facetious, if the hardware was open, someone would have already written a custom boot loader for this :P)

Thanks for this. I was feeling similarly reading the original post.

I was trying to keep an open mind, it's easy to be wrong with all that's going on in the industry right now.

Thanks for clarifying some of the details back to what I was originally thinking.

Interesting, thanks for the info, I'll do some reading on what you're saying. I agree, you're right about JS having issues with hiccups in the UI due to scheduling on a single process thread.

Makes a lot of sense, cool that the garbage collector can run independently of the call stack and function scheduler.

I think we're having a completely different conversation now. The parent comment I originally replied has been edited so much that I think the context of what I was referring to is now gone.

Also, I wasn't talking about building network layers, I was explicitly referring to things that use a network layer... That is, an application receiving streams of enumerable network data.

I also agree with what you're saying, we don't want UInt8, we want bits and bytes.

I'm really confused as to why the parent comment was edited so heavily. Oh well, that's social media for you.

What happens when I send an extremely high throughput of data and the scheduler decides to pause garbage collection due to there being too many interrupts to my process sending network events? (a common way network data is handed off to an application in many linux distros)

Are there any concerns that the extra array overhead will make the application even more vulnerable to out of memory errors while it holds off on GC to process the big stream (or multiple streams)?

I am mostly curious, maybe this is not a problem for JS engines, but I have sometimes seen GC get paused on high throughput systems in GoLang, C#, and Java, which causes a lot of headaches.

Adding types on top of that isn't a protocol concern but an application-level one.

I agree with this.

I have had to handle raw byte streams at lower levels for a lot of use-cases (usually optimization, or when developing libs for special purposes).

It is quite helpful to have the choice of how I handle the raw chunks of data that get queued up and out of the network layer to my application.

Maybe this is because I do everything from C++ to Javascript, but I feel like the abstractions of cleanly getting a stream of byte arrays is already so many steps away from actual network packet retrieval, serializing, and parsing that I am a bit baffled folks want to abstract this concern away even more than we already do.

I get it, we all have our focuses (and they're ever growing in Software these days), but maybe it's okay to still see some of the bits and bytes in our systems?

This reminds me of the Unreal Tournament: Xan episode from the Secret Level series.

Link for those curious or confused as to what I'm talking about: https://www.youtube.com/watch?v=1F-rAW3vXOU

Forcing AI to fight in an arena for our entertainment, what could go wrong? (this was tongue in cheek, I am fully aware LLM's currently don't have conscious thoughts or emotions)

Ah, yeah. I see what you're saying. That is more of an open vs proprietary platform problem.

I am fairly sure that nVidia intentionally wants to keep addressable memory as a feature only for CUDA (among many other features).

Having CUDA be far superior to other shader code methods is good for vendor lock-in to their hardware, their software, their drivers, etc.

It is really sad seeing that the addressing is possible, but they won't open it up to everyone.

I also want what you're describing. It seems like the ideal "data-in-out" pipeline for purely compute based shaders.

I've brought it up several times when talking with folks who work down in the chip level for optimizing these operations and all I can say is, there are a lot of unforeseen complications to what we're suggesting.

It's not that we can't have a GPU that does these things, it's apparently more of a combination of previous and current architectural decisions that don't want that. For instance, an nVidia GPU is focused on providing the hardware optimizations necessary to do either LLM compute or graphics acceleration, both essentially proprietary technologies.

The proprietariness isn't why it's obtuse though, you can make a chip go super-duper fast for specific tasks, or more general for all kinds of tasks. Somewhere, folks are making a tradeoff of backwards compatibility and supporting new hardware accelerated tasks.

Neither of these are "general purpose compute and data flow" focuses. As such, you get the GPU that only sorta is configurable for what you want to do. Which in my opinion explains your "GPU programming seems to be both super low level, but also high level" comment.

That's been my experience. I still think what you're suggesting is a great idea and would make GPU's a more open compute platform for a wider variety of tasks, while also simplifying things a lot.

My method was simply to think. To think hard and long... This method never failed me. I always felt that deep prolonged thinking was my superpower. I might not be as fast or naturally gifted as the top 1%, but given enough time, I was confident I could solve anything.

This mindset is a healthy and good one. It is built on training yourself, learning, and practicing a discipline of problem solving without giving up.

Persistence is something we build, not something we have. It must be maintained. Persistence is how most good in the world has been created.

Genius is worthless without the will to see things through.

I don't mean to come across as far too cynical, but in what world has a software license ever stopped the greedy and powerful from pillaging the IP of other people smaller and weaker than them?

In my opinion, libertarianism in software is a hollow dream that leads people to make foolish decisions that can't be protected. This makes it easy for corporations to exploit and quash any barely audible opposition.

Almost as if by plan, the libertarian mindset has eroded and weakened open source protections, defanging and declawing it every step of the way.

Exactly

Sounds like the system is working as intended...

Not trying to be glib here. This feels like the embrace, extend, extinguish pattern that we jokingly used to think was only Microsoft. It is now becoming more and more obviously the modus operandi of the entire enterprise software ecosystem.

I believe you are correct to be frustrated and ringing the alarm bell. This is a "death of the commons" moment for OSS.

It almost always indicates some bottleneck in the application or TCP tuning.

Yeah, this has been my experience with low-overhead streams as well.

Interestingly, I see a ubiquity of this "open more streams to send more data" pattern all over the place for file transfer tooling.

Recent ones that come to mind have been BackBlaze's CLI (B2) and taking a peek at Amazon's SDK for S3 uploads with Wireshark. (What do they know that we don't seem to think we know?)

It seems like they're all doing this? Which is maybe odd, because when I analyse what Plex or Netflix is doing, it's not the same? They do what you're suggesting, tune the application + TCP/UDP stack. Though that could be due to their 1-to-1 streaming use case.

There is overhead somewhere and they're trying to get past it via semi-brute-force methods (in my opinion).

I wonder if there is a serialization or loss handling problem that we could be glossing over here?

When I'm in these situations, I try and put myself into the IP holder's shoes.

"if I spent the time, risk, effort, and money to develop the pre-eminent protocol and hardware used by most TV's in the world... would I want to give that work away for free?"

I think the answer is probably no for most people.

Because most of us are not the IP holder, they think this technology should just be free (as you stated earlier).

This lack of empathy and care for others (even IP holders) is largely why these draconian IP rules and contracts exist. It's why there are whole crazy NDAs around the HDMI spec. It's because every time someone is given even a slight look under the covers, they try and steal it, because it's worth a lot of money.

This is a nuanced variant of "this is why we can't have nice things" all over again.

For anyone who wants to see some real workstations that do this, you may want to check out Alex Ziskind's channel on YouTube:

https://www.youtube.com/@AZisk

At this point, pretty much all he does is review workstations for running LLM's and other machine-learning adjacent tasks.

I'm not his target demographic, but because I'm a dev, his videos are constantly recommended to me on YouTube. He's a good presenter and his advice makes a lot of sense.