blihp

no profile record

comments

8 mesi fadiscuss

I gave up on heavily customizing the UI after a couple of top variants (where I would lose said customizations for a variety of reasons) over the years so I run a fairly vanilla config: I like both the look and the information density of btop over htop out of the box.

8 mesi fadiscuss

Not necessarily as even the factory produced optical discs have had issues with de-lamination, oxidation etc. Of course a lot of that had to do with companies cheaping out on manufacturing in order to make that last tenth of a cent of profit as they tend to do.

9 mesi fadiscuss

Not possible given the anemic memory bandwidth [1]... you can scale up the compute all you want but if the memory doesn't scale up as well you're not going to see anywhere near those numbers.

[1] The memory bandwidth is fine for CPU workloads, but not for GPU / NN workloads.

9 mesi fadiscuss

When I bought a PS 1 around 1998-99 I paid $150 and I think that included a game or two. It's the later in the lifecycle price that has really changed (didn't the last iteration of it get down to either $99 or $49?)

9 mesi fadiscuss

By the time that could feasibly come to fruition, I suspect the AI bubble will have long since popped. Despite making decent GPUs for graphics, AMD can't seem to get its act together on the GPU compute front.

9 mesi fadiscuss

Try to use AMD GPU's for AI and you'll understand. Unless you have lots of your own engineers to throw at making their stuff work, it's easier for most companies just to keep throwing money nVidia's way.

10 mesi fadiscuss

There are very few recently launched pure open source projects these days (most are at least running donation-ware models or funded by corporate backers), none in the AI space that I'm aware of.

3 anni fadiscuss

In the dark ages when internet access was limited and/or via dialup for most of us, there were several tools and protocols to work with what we had: email, ftp and usenet were some of the main ones. Usenet was basically a primordial set of distributed forums platform (and quasi-social network) where copies of the data were stored locally. It was how a lot of information got disseminated prior to the mid-90's when the web took off and then over.

4 anni fadiscuss

It's only illogical in retrospect now that Unix/Linux 'won'. Back then, every platform had its own quirky OS and hardware. Of the bunch, I found the Amiga running AmigaOS the among the least quirky and illogical.

4 anni fadiscuss

A loaded up Amiga (i.e. add a CPU accelerator board, more RAM than most PCs could handle, specialized video processing cards etc) could get into the low end of workstation territory. But you are right that architecturally, they had more in common with high end PCs than workstations of their day. The Amiga's main claim to fame from a hardware standpoint was their specialized chipset.

4 anni fadiscuss

They allow you to spend much less time thinking about resource constraints and/or performance optimization and just focus on what you're trying to get done and/or do more than would be possible with conventional systems. Workstations let you buy your way past many limitations.

The closest example today would be people like developers, AI researchers, 3D designers and video editors buying high-end video cards (quite possibly multiple) running in Threadripper systems. They're paying up for GPU power and huge amounts of cores/RAM/IO bandwidth/whatever to either do something that isn't feasible on a lower end system or to complete their work much more quickly.

4 anni fadiscuss

Those are just two options (I'm not a big fan of either)... there are a myriad of other options available.[1] While I disagree with your assertion that Linux desktops are not secure, I would agree that making them more secure is not trivial. If you changed your assertion to 'they are not secure by default', I would agree with you.

I would disagree with 'has to be comfortable to use' as that is often at odds with 'secure'. Some of the things I do to secure my system make infrequently done/high risk things quite uncomfortable to use. Not because I wanted to make it uncomfortable, but because that's what it took to get the level of security I desired.

[1] I would also argue that spending too much effort here before addressing other attack vectors first is rather silly. (i.e. web browser, network, minimizing usage of/isolating 3rd party binaries)

4 anni fadiscuss

It's more often a case of misaligned incentives than being all that difficult. When your business model (both Google's and most 3rd party developers) depends on constantly streaming telemetry from a device to a server you're going to have battery life challenges. Much of Google's effort has gone to providing decent battery life while still providing the telemetry. No doubt that a fair amount of effort has gone into specific use cases like background streaming audio apps (i.e. phone/music/etc) but the hours those take are a drop in the bucket compared to making the whole advertising ecosystem work (efficiently enough) on mobile.

4 anni fadiscuss

You underestimate how much other low hanging fruit there is. Yes, at some point using less integrated hardware (due to driver issues) will dominate but we are pretty far from that being the limiting factor.

4 anni fadiscuss

Sure, if you run (most of) them in their default configuration. However, they can trivially be made much more secure which is one of the appeals of Linux to some: you're not limited to whatever set of compromises a vendor decided was acceptable.

4 anni fadiscuss

> GrapheneOS and AOSP are Linux-based and there are no closed source kernel modules.

I ran AOSP builds for years and that's a half-truth at best. Sure for the kernel proper, you have the source. However, there are a fair number of closed source drivers for the GPU, modem, wifi etc. From the GrapheneOS Wikipedia page[1] it sure looks like they're following this model.

If I am mistaken and there is a miraculous state-of-the-art SoC with completely open source drivers being used by a major handset maker, do tell. You'll be a hero in the open source world for pointing out something everyone else has overlooked.

> Sticking to an LTS kernel branch for the lifetime of the device isn't due to anything closed source.

It has everything to do with things being closed source. Try doing a Linux kernel major version upgrade with binary-only drivers for key components sometime. It sounds like the only reason GrapheneOS works is because they're 'drafting' off of the kernel and driver work done by Google, not that they've cracked that particular nut themselves. Nothing wrong with that, but it does limit the useful life of a device to the first major security issue they can't fix due to a lack of source code.

Regarding the rest of your response, you're assuming that I was speaking to the Librem 5 specifically, I was not. Notice that I was only speaking about the goal of a 'pure' Linux phone since that was what seemed to be being asked about. Personally, I have a PinePhone[2] and wasn't interested in rehashing the various issues with the Librem 5.

[1] https://en.wikipedia.org/wiki/GrapheneOS

[2] which itself is far from perfect, but comes a lot closer to being a 'pure' Linux phone.

4 anni fadiscuss

For around the house/office, a two (or more) device solution is fine for many. But when you're truly mobile people generally want to minimize the number of devices they have to deal with. For most Linux users, including myself, we're not there yet but the day is getting closer.

What is this 'if' of which you speak? I've been using Linux as my daily driver desktop for over a decade ;-) It's not likely to ever become a mainstream desktop, nor are these Linux phones, but there are a fair number of us who don't care if they do or not. We just want them for ourselves.

4 anni fadiscuss

The general idea behind any 'pure' Linux phone is to have a device that you can trust at least as much as a desktop running Linux. Security is definitely a key aspect for many. But it's also the flexibility of not being locked in to anything on the software side. Ideally, it also extends the useful life of the device as when vulnerabilities and bugs are found, they can be fixed rather than junking the device for lack of updates. It's still pretty early days re: 'full' Linux on mobile and so it doesn't look like much yet... it takes time. Desktop Linux didn't look like much in 1994 either.

I'm not familiar with GrapheneOS but I assume it follows the usual model when repurposing Android devices of taking various closed source blobs (i.e. drivers etc) and rebuilding the open source bits around them? If so, this approach usually locks you into a Linux kernel version to remain compatible with the blobs which limits you on kernel features and fixes as well as who knows what exposure the blobs have to offer, which also will likely never get updates.

5 anni fadiscuss

Working hours wouldn't matter. Steve was a very well connected CEO and probably better connected than most re: Japan. Canon was a significant partner with and investor in NeXT, for example. So it's not a stretch to imagine he knew connected people over there. All his secretaries probably needed to do was get in touch with the staff (more likely, the personal secretaries) of no more than a few of his contacts within a couple of degrees of someone high up at Nomura and say 'Steve needs a favor'. Someone knew someone and so on... and it's done.

5 anni fadiscuss

Sure, but that's a different end of the issue than I was referring to. I was pointing out that just taking code off of github wouldn't avoid the use case. Any published code from any public source is likely to eventually be used this way by someone.