News for hackers. Stuff that matters.

jimjag

Re:BeanShell 3.0.0RC1 Released on Monday October 12, 2026 @08:40AM (#50055582)
First Release Candidate for the resurrected BeanShell project is now available.
Re:BeanShell3 in Development on Friday September 18, 2026 @01:52PM (#49757845)
Who tinkled in your corn-flakes?
Re:BeanShell3 in Development on Friday September 18, 2026 @01:51PM (#49757825)
That needs to be updated... Beany is ALv2 :)
Re:BeanShell3 in Development on Friday September 18, 2026 @10:21AM (#49754824)
After a long hiatus, BeanShell3 is back on schedule.
Re:Too much discussion of the XOR swap trick on Thursday April 16, 2026 @09:10AM (#47792461)
You can even do it with complex images in a multi-color bitmap. I do it with my 6502 SBC setup: https://github.com/jimjag/JJ65c02/blob/main/Software/pico-co...
Re:LibreOffice and the Art of Overreacting on Thursday March 26, 2026 @09:04AM (#47529945)
LibreOffice suffers from an extreme inferiority complex, which is why they overreact and get overly defensive about _everything_.
Re:The Java Ring: A Wearable Computer (1998) on Monday December 15, 2025 @08:49AM (#46274495)
I still have 2 of these.
Re:Several core problems with Rust on Monday November 24, 2025 @09:26AM (#46034474)
I think people are missing the main point. The real issue with Rust is that it is a designed language which is really tuned and optimized for a specific use case. And for that specific usage, it is really, really good. But even so, it requires a lot more up-front work, due to the limitations and restrictions it imposes.

But it is NOT a good general purpose language. And, maybe to be putting words into the author's mouth, that is their main beef. That every seems to be pushing "Rust All Things" even when it makes no sense, and even if there are much better alternatives available.

So for such comments as "so what about compile time", the issue is that for some, compile time _is a concern_. If it isn't for you, great. But you just can't discount what are valid concerns for others.

People seem to forget that languages are _tools_, and as such, have different sweet-spot use-cases.

Re:Vibe Physics on Monday July 21, 2025 @10:48AM (#44635771)
Billionaires Convince Themselves AI Chatbots Are Close to Making New Scientific Discoveries
There are some wheels, for example, 'lxml' that bundle in their binary possibly incompatible external libraries, or older libraries than what you would like. This can cause library conflicts.
It helps, that's for sure. But this sort of knowledge should not exist in the environment in any case. It should be part of the canonical package list, and not hidden away elsewhere. The whole idea of a dependency manager should be a centralized and consistent way to install everything you need and not be dependent on what values may or may not exist as a env-var.
This has the same issue as so many package managers for Python, namely, it doesn't provide a way for --no-binary to remain sticky.

There are times when you do NOT want the wheel version to be installed (which is what --no-binary implements in pip), but so many package managers including uv don't provide that core, basic functionality. At least for those that do use pip behind the scenes, like pipenv, one can still use the PIP_NO_BINARY environment variable to ensure this.

So I'll not be migrating any time soon.

Re:Matt's Script Archive (1995) on Monday March 03, 2025 @08:03AM (#43241327)
It cannot be stressed enough how _vital_ these scripts were to making the WWW an actual functional technical resource; These scripts were a key, if not the key, in growing the actual interactive web, showing the potential of CGI, and in guiding the evolution of web2.0 and beyond.

Its value and place in history can't be overstated.

Re:Once You're Laid Off, You'll Never Be the Same Again on Tuesday January 28, 2025 @07:56AM (#42851763)
"You should never worry about betraying your workplace because given the chance, your workplace will definitely betray you. Loyalty to individuals. Relationships. That's what makes the world go round."

- Raymond Reddington.

Re:Welcome to the Antarctic Fire Department on Wednesday November 13, 2024 @11:26AM (#42127439)
I would have assumed that the workload would be similar to what Fred and Barney expected at the Bedrock Fire Department.
Re:There are 665 open licences, most are pretty rubbish on Friday September 20, 2024 @10:31AM (#41602384)
But it is that exact kind of unknown which makes most people and entities avoid those licenses in the 1st place. If the goal is to significantly limit the distribution and reach, I guess it makes sense, but if the goal is to have people actually use it (and therefore hopefully contribute to it), then those licenses and the projects that use them are actively avoided.
Re:There are 665 open licences, most are pretty rubbish on Thursday September 19, 2024 @08:33AM (#41591164)
Most of the licenses discussed in the article are demonstrably NOT open source licences at all.
Re:TinyMCE (also) moving from MIT to GPL on Wednesday March 27, 2024 @09:42AM (#39838971)
The entire work can be licensed under GPL, but those parts that were MIT remain, individually, still under MIT. MIT specifically and explicitly allows for 'sublicense'ing
Re:Redis License Changed on Thursday March 21, 2024 @08:38AM (#39777788)
Not all CLAs are the same... for example, the CLA from the ASF is NOT a copyright assignment. Other CLAs _are_.
Re:Redis License Changed on Thursday March 21, 2024 @08:35AM (#39777747)
How a license which conflicts with the OSD can "clearly (be) an open source license in the full spirit and original intent of open source" is beyond me.
Re:Should I Open Source my Company? on Monday January 22, 2024 @08:08AM (#39089092)
Open Source is not a business model.

Open Source is a licensing and development model.

Re:A/UX: Apple Unix for Macintosh on Friday December 29, 2023 @07:00PM (#38811635)
blush

Thank you everyone for the kind words

Re:A/UX: Apple Unix for Macintosh on Friday December 29, 2023 @04:31PM (#38810438)
Well, that's assuming a very specific, and stale, development direction; I think we would have seen a more native and natural migration to something very macOSX like. Sure, not exactly macOSX as we know it today, but something that we would have used and appreciated as much as what we now have.

What made OpenStep so useful was that it was immediately _available_, but imagine if it was used as a source for tech to be added to the continuing A/UX development, instead of basically being Step One.

Re:A/UX: Apple Unix for Macintosh on Friday December 29, 2023 @01:06PM (#38808130)
Yep... the move from m68k to PowerPC was pretty much the deathknell. To really be a successor to A/UX, the core code would have had to be ported to that chip, and the amount of work required was simply too expensive to be justified. I also had heard, unofficially at the time, that Apple's license for the UNIX parts of A/UX were specific to the m68k architecture, and that they would have had to renegotiate the license to even be allowed to port it to the PowerPC.

What is interesting is that after A/UX died, some alternatives did spring up, such as Yellowdog Linux (which was NOT a macOS/UNIX hybrid, but rather vanilla Linux).

It is a shame, because if Apple had continued in investing it it, we would have had MacOSX much, much earlier.

Re:A/UX: Apple Unix for Macintosh on Friday December 29, 2023 @07:37AM (#38804270)
This was one of the most important OSs in my life, for a number of reasons.

Older »