blihp

I was in a similar situation not too long ago and found that describing the part to ChatGPT worked. I did have to course correct it a couple of times, but eventually it got me the answer I was looking for.

Probably a lot of both. Disney is almost single-handedly the reason copyright is as screwed up as it is here in the U.S. as they have been the primary corporate actor behind the copyright extensions over the past several decades.

What are you using to read/post to HN? That would likely be enough to run Cuis on. I've run Cuis on a Pi 2 and that was fast enough to provide a reasonable interactive development environment with a useful amount of memory. Running without a GUI is generally not likely to lead you in an interesting direction. The thing to understand is that the Squeak VM expects to encapsulate 'high level' hardware including a bitmapped display, keyboard, mouse and a sound device. Anything less than that and you're putting yourself more in the role of VM developer instead of Smalltalk developer. (Honestly, if one were starting from scratch today there are more interesting places to start than the Squeak VM as its lack of SMT support is becoming a crippling limitation. This is a design limitation of the language/environment and can only be overcome fundamentally rethinking a couple of core concepts.)

> well that is true, except one case when vm doesn’t run on the desired hardware/software combination. So in my case I had quite a story of trying to port vm unsuccessfully so far . ( see details : https://news.ycombinator.com/item?id=38820927 )

The available pre-built VM's should support most 32-bit and 64-bit x86 and ARM Linux systems. For 32-bit you might have to go back to a slightly older release (I'm not sure if 32-bit has been deprecated yet or not) but you'll still get 99.9% of the experience. I think Windows is fully supported but not sure about OS X since the move to ARM as I've heard some grumbling about issues on that platform.

If you're on a non-x86/ARM system, you would have to build from source but won't be able to use the 'fast' VM (i.e. cog/spur) and would have to fall back to the interpreter VM. I managed to get it running on a couple/few ARM-based systems back before there was official support for ARM as a platform and it wasn't too difficult. IIRC, it took a couple/few #define's to shut the compiler up and things mostly worked on Linux. (the remaining issues were long ago fixed due to bug reports and the JIT side of things once ARM became a supported platform)

> Any advice about how to move forward with it? How hard it is to extract the bare minimum of the language from the image? All I need is basic set with repl , nothing more. As I understand it should be possible but requires deep knowledge of the image which one does not possess in the beginning. I really wish to play with language and study it and with current limitations it is only possible on a hardware where the vm doesn’t run out of the box.

You're not likely to get very far with just a repl on a Squeak-derived (i.e. Cuis/Squeak/Pharo) Smalltalk. GNU Smalltalk is going to work better with that approach but you'll lose most of why people love Smalltalk, IMO.

I'd be surprised if based on what I said above you can't get a pre-built image running on a computer you have access to. If that's the case, let me know what you're trying to run it on and I'll see if I can give you a pointer to something that would work.

There isn't one. Smalltalk implementations, including Cuis/Squeak/Pharo, are image-based. So applications in their world get packaged more like a word processor/spreadsheet document than a traditional executable from other languages/environments. You distribute the .image file (and usually a .changes file as well... but that is more or less optional via changes you can make to the .image) which is loaded and run by the VM, which is the actual executable.

The license allows you to distribute your applications either as standalone .image files or bundled along with copies (modified or not) of the VM, but they are still discrete files.

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.

While it isn't impossible, I agree that it's unlikely in the current political climate. If we could ever get back to a place where government was even remotely functional, it could almost trivially address the right to repair issue via procurement policies (i.e. 'we will only buy from suppliers who...')

Meta/Yann LeCun were generating the hype around Galactica that caused expectations to be different. You can't say things like 'Type a text and Galactica will generate a paper with relevant references, formulas, and everything'[1] and expect your LLM not to make you look foolish. It wasn't about pushing the model to the limit, it was about setting realistic expectations of what it could do.

[1] https://statmodeling.stat.columbia.edu/2022/11/23/bigshot-ch...

That's usually the case as the hardware encoders tend to make tradeoffs in the direction of lower transistor count / faster frame processing while software encoders have the luxury of going for higher quality.

AV1 hardware encode just started rolling out with the most recent GPU architectures so the majority of hardware still has to do software encoding. I'd also guess that a very large fraction of the hardware out there doesn't even have hardware decode for AV1 since it was only the last generation of GPUs that got that. AV1 is mainly solving problems for the platform owners (google/netflix/facebook etc) and h264 will probably serve typical users for years to come especially if they have that one device they want to keep using that only supports h264.

For GPU compute drivers on the majority of their consumer cards on Linux the claims are most certainly true.

IIRC, nothing below the 6800 is supported by ROCm... so the lion's share of their installed base of the 6000 series is excluded from 'official' support. nVidia's compute drivers support all of their devices and have across multiple generations, AMD's support only the low volume devices and drop support for older generations seemingly almost as fast as they are released.

They didn't know that at the time. Not an outrageous story as hotter is generally better for pizza ovens.

Sorry for the lag in my reply (I just noticed your response)... I very much appreciate the info as I found the lack of official RISC-V support in 12 surprising. I hadn't read about the blockers to being ready for the release which makes perfect sense. Looking forward to seeing in in 13!

In the interview he runs down the issues they encountered going down the pure AI accelerator path. It sounds like they've decided the opportunity wasn't there (i.e. too hard) so they've pivoted.

The Debian project has been historically a vocal proponent for open hardware/firmware/drivers etc. and here we are in 2023 having Debian somewhat controversially acknowledging that proprietary firmware may be required at least by some users, to some degree. So I am suggesting that if they really want to get there that they might need to help facilitate the change they would like to see.

Is RISC-V the be-all, end-all? No, but it could help them get a lot closer than they're likely to get with any of the proprietary ISAs.

You can run a reasonably current Debian install by just switching to the testing repos after you install a stable release. This mostly works pretty well but occasionally[1] you'll have an issue. While you could get absolutely up to the minute software (from a Debian standpoint) using the sid (i.e. unstable) repos, I wouldn't recommend it as breakage is quite common there as they are working through various packing issues and that repo lives up to its name.

[1] every couple of years in my experience... typically as they're getting closer to a new release and package breaking changes are needed/slip through.

That doesn't answer the question. It's still 'unofficial' per https://wiki.debian.org/SupportedArchitectures

If you want the maintain the status quo you support the hardware that has the most users, if you want to change it you also support the hardware you want them to use.

While I'm glad to see proprietary firmware both included and segregated in its own repo, I'm wondering why RISC-V wasn't added as a supported architecture in Debian 12? It seems like that supporting at least an open ISA would move closer to the possibility of what Debian wants to see happen... so why isn't it as a distro helping to make it happen?

Heh... yes, that was a popular joke at the time and one of many cautionary tales in picking a multi-word domain name.

There was always the possibility of some sort of aggregator/other front end sitting on top of the SO data. We just didn't know exactly what a successful one would look like until relatively recently. I always limited how much I contributed based on that as likely outcome. Discontinuing the data dump is a much bigger deal to me and completely changes the value proposition of their various sites.

Because despite claims to the contrary most of these sites/projects aren't created for altruistic reasons, they were created to make money (at some point). Cashing out is typically part of the long term plan.

In the case of Stack Overflow, I think the reason for the data dumps was two-fold: one of the original founders (who left long ago) came across as at least idealistic and wanting to do the right thing. The other was pragmatic and most likely always thinking about the money angle. However, the other founder likely also saw the value of the data dumps from a PR standpoint which was quite valuable as they were initially trying to replace expertsexchange.com that paywalled most of the content. IIRC, they discussed the data dumps in the early days of their podcast.

Now that there's big money to be made from machine learning (both the models and the data they are trained on), they've likely decided 'screw it' on the PR value of the data dumps and would rather get some of that sweet, sweet machine learning money.

Even then, not really. Most of the time they had 4-6 hours of actual programming that they just repeated.

> is this a sign that RH can't afford to run their business?

Afford has nothing to do with it... IBM will continue tightening things up with/at RH to get their ROI.

The same reason most of AMD's 'open' initiatives don't gain traction: they throw it out there and hope things will magically work out and that a/the community will embrace it as the standard. It takes more work than that. What AMD historically hasn't done is the real grunge work of addressing the limitations of their products/APIs and continuing to invest in them long term. See how the OpenCL (written by AMD) Cycles renderer for Blender worked out, for example.

Something AMD doesn't seem to understand/accept is that since they are consistently lagging nVidia on both the hardware and software front, nVidia can get away with some things AMD can't. Everyone hates nVidia for it, but unless/until AMD wises up they're going to keep losing.

QuickBooks and GnuCash handle the accounting, which supplies the data needed for your taxes. However, they won't spit out your tax forms as that's a separate task and not likely something open source is going to tackle anytime soon given how convoluted, arbitrary and constantly changing tax laws can be. Most open source developers would rather go in for multiple elective root canals before dealing with that.

Yes, it's possible to do your own taxes but it's a headache the first time or two you do it. I have never found any open source software to help with it beyond things like LibreOffice Calc to do various tax worksheets.

The problem with FPGA's isn't the hardware... it's quite complete and capable. It's the software stack you're forced to access most of them via that makes them a non-starter for many/most hobbyists. (cost is a major issue, but hardly the only one) My guess is that as low cost producers who have embraced the existing open source FPGA software being developed start producing higher end parts (more recent process nodes, large LUT count etc), that's when you'll really start to see them take off in the hobbyist world.

I think the OP isn't even talking about 2006-level capability but rather something akin to 3D printing for semis that approached even early (i.e. somewhere in the 1960's-1980's range) level fab capability for hobbyists. Obviously it doesn't exist currently, but that's the dream for some.

That's only when a mid-level or lower person/group wants to make a change. If it comes from the C-level, it gets done very quickly.

It's more than just that: for the money, their consumer GPUs don't compete in compute tasks (especially inference/training) and their Linux compute drivers are a pile of steaming garbage on consumer hardware. It's really interesting/depressing to watch as they've done a nice job of supplying good open source graphics drivers. They really seem to be lacking something at a leadership level in terms of understanding GPU compute outside of specific enterprise/scientific use cases.

You just copy/paste the text of the complaint (this is why you hear many complaining about maximum context size... for some use cases you want to feed in a lot of text)