jimjag

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...

LibreOffice suffers from an extreme inferiority complex, which is why they overreact and get overly defensive about _everything_.

I still have 2 of these.

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.

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.

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.

"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.

I would have assumed that the workload would be similar to what Fred and Barney expected at the Bedrock Fire Department.

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.

Most of the licenses discussed in the article are demonstrably NOT open source licences at all.

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

Not all CLAs are the same... for example, the CLA from the ASF is NOT a copyright assignment. Other CLAs _are_.

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.

Open Source is not a business model.

Open Source is a licensing and development model.

blush

Thank you everyone for the kind words

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.

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.

This was one of the most important OSs in my life, for a number of reasons.

Actually, its reverse proxy implementation is quite capable and performant.

No Yoyodyne? John BigBoote is gonna be sad

IMO, the reason for the initial success of HTTP (1.x) was due to its extreme simplicity. Things like text-based protocol, straightforward stateless design, capability to implement both server and client in easy, basic code. All this meant that the protocol itself was stable, usable, and a reliable standard to use.

The current path is to drastically increase complexity due to the demands of the content provider overlord(s); Basically, in order to better accommodate the needs of Google (and a handful of others), we must redefine things for everyone. It's becoming a complex, over-designed protocol that is being crammed down people's throats, instead of a protocol that is embraced because it makes sense.

This should be fixed now...

FTR: The correct address is ospo-heroku-credits@salesforce.com

I truly believe that A/UX doesn't get the credit it deserves. Was it ambitious? Sure. Did it it fully succeed in the goals it set for itself? Not really. But it was really a very nice integration of the Finder and UNIX. After all these years, I still look back on it with fondness. It certainly was a cornerstone platform for me.

Why does no one pick it anymore? The reason is twofold: (1) the amount of FUD that surrounds it, based on old comparisons of nginx and Apache httpd 1.3 or 2.x using Prefork and (2) cool-kid syndrome. This thread itself is a perfect example.

X == Apache httpd 2.4

Hmmm... looks like nothing more than a weblog analyzer. Someone correct me if I'm wrong. It's not "real time" since it can only report on what the web-server has done not what it is doing. AFAIK, nginx has nothing like Apache httpd's mod_status... at least, nothing open source.

Location: Maryland

Remote: Yes

Willing to relocate: No

Technologies: Open Source Strategy, Community

Résumé/CV: http://www.jimjag.com/JimJagielski-CV.pdf

Bio: http://www.jimjag.com/About_JimJag.pdf

Wikipedia page: https://en.wikipedia.org/wiki/Jim_Jagielski

Email: jimjag at gmail.com