... EMACS is a full word processor? It's a bit spartan in terms of how the interface feels, but functionally it's a lot better than what modern writers get given in vibecoded packages
Well, the damage to the ecosystem from the BP oil spill will likely last a few hundred years. The damage from Chernobyl will likely last for a few tens of thousands of years.
The environment around Chernobyl has already recovered, and is now healthier than it would have been without a nuclear disaster (due entirely to it's function as a human repellent).
The area is still bad for humans; but not terrible for the ecosystem.
Sure. In the same way that flying is far safer than driving. There are massive amounts of safeguards in place to keep it as safe as possible. The problem is that when something goes wrong, it goes very, very wrong. This is why some people fear flying and nuclear power.
Even ignoring climate change, coal kills _literally a thousand times as many people as nuclear per kWh_ (largely due to air pollution; living vaguely near a coal plant measurably shortens your life). But people aren’t necessarily great at intuitively understanding risk; nuclear _feels_ much scarier.
>But people aren’t necessarily great at intuitively understanding risk; nuclear _feels_ much scarier.
Nuclear is much scarier. Your argument fails to account for the extreme effort spent in order to keep it safe!
In the US, high explosives kill fewer people per year than painkillers. Despite this extraordinary statistic, we're not about to let anyone buy high explosives over the counter. Because we know that high explosives are in fact, much more dangerous than painkillers.
Same goes for nuclear. We have kept it safe(ish) so far, but we know what can happen if we don't.
You don’t even have to look that far ahead, people area already dying every year due to the direct toxicity (Including radionuclide release!) of fossil fuel emissions.
One relevant study for those not aware: https://pmc.ncbi.nlm.nih.gov/articles/PMC11301007/
I mean every single major nuclear plant accident is from reactors built in the 1960s. I think we are simply better at building them and it is no longer a question of “when”
Assuming no outside forces suddenly intentionally do something to it. Attacks against infrastructure aren't uncommon. Having infrastructure that is well known to take quite some time to spin down with the consequences being ten thousand years of salted earth is quite a big bullseye.
Which I would still argue is far from making a "when" realistic. This entire comment chain started on the matter of cost. If someone has a reactor, the enemies won't try to explode. They will go Temüjin on it and seize it.
Statements of certainty can be weaponized even more. That same rhetorical opponent would be just as happy to point out some exceedingly rare edge-case counter-example (no matter how dubious) and crucify the entire study (or worse, haul you in front of Congress and try to pepper you with "gotcha" questions in the hopes of catching you in a "lie" so they can make an example out of you). You rhetorical opponent is not going to argue in good faith either way and their audience are not people who will care.
Scientists write for other scientists who already know why they use the language they use. Compromising that language to try to cater to fools who couldn't care less about the truth would just make the scientist a greater fool for trying.
>Scientists write for other scientists who already know why they use the language they use. Compromising that language to try to cater to fools who couldn't care less about the truth would just make the scientist a greater fool for trying.
This is a better version of the point I was trying to make, thanks. The framing / who is the audience makes the biggest difference. Had fun watching Digger.
Is it? Because at the very least, modern life involves the mass production of plastics, mining of various minerals, and the use of copious amounts of energy. That last one is only kind of solved (as long as everything works and nothing breaks), but I have yet to see any convincing evidence that there is any feasible substitute for the first two.
The solution to the first two is reuse. With enough energy, some form of recycling of becomes feasible for pretty much anything. No oil? Just make plastic from atmospheric CO2!
Is it a solution if the masses refuse to trade cheap convenience for more expensive and burdensome products/processes? Theoretically yes, but realistically no.
> I’m glad it’s still hard UX entry to many as we don’t need many there. Just those enough few who get it
Of course, we can't forget the rampant elitism among sysops (and no, I'm not counting myself outside of that group - I was downright insufferable back in the day).
Definitely get a nostalgia buzz thinking about the early 1990's BBS scene. Had a very vibrant community of BBS users in my city during that time.
It is ironic and somewhat interesting that the biggest aspects of the BBS scene that most people seem to miss (the community/local culture, meeting like-minded people in real life, some of the games, ANSI art, Echomail discussions), are all things borne from the technical limitations of the time. Slow modems and high long distance charges meant most people kept to their local boards. Games had to be designed in text with only a rudimentary colour scheme (sure, there was RoboBoard, RIP, NAPLPS and other graphical protocols - none which really caught on all that much) and still be compelling. Most were limited turn based (which meant being forced to only spend a couple hours a day playing, then having to wait). "World-wide" networks like FidoNet were dog-slow by today's standards (it was a toss-up whether a message would reach its recipient faster on an FTN network or via snail-mail), so discussion threads would last for days but only have several hundred messages in them to sort through.
I remember the years and work spent to try to improve on these limitations. Galacticomm and eSoft had their huge hackish ways to get past the non-multitasking nature of DOS and the IRQ limits of PCs to allow people to run huge multi-line boards on regular PCs. We saw Planet Connect dramatically lower the cost of distributing FidoNet packets via satellite downlink (still needed telephone uplink if you were sending, though). We saw big serial breakout boards and modem boxes (Galactibox?) come out. And of course, faster modems. Up to rip-roaring 33.6kbps speeds at the peak of the BBS era.
Ultimately, the internet and the "real" operating systems that are commonplace today overcame those limitations in ways that were pretty unfathomable to most of us common BBS users and sysops of the day. Unfortunately, BBS's today really only appeal to those of us who had lived through the struggle of configuring COM ports or QWK readers (or for many of us, a tosser/scanner, door game, FOSSIL driver, or getting DESQview working just right).
I run a "modern" BBS, Xibalba. Something I find is actually quite a few "callers" visiting the board are new blood. Younger generation that never lived through or touched a BBS but usually fall into one of two camps: 1 - "I'm tired of the modern corporate Internet", 2 - I just want to learn about history.
People still login to play games (I'm writing a new one!), and chat. Downloads here and there when you have hard to find history items, etc. Certainly nothing like it's heyday, but enough to keep me happy anyway :D
Reflecting, I feel like those limitations are what forced things to be good. With the limited toolkit, you had to focus on ux in a way that's not realistic to do today. So many classic games had excellent gameplay in spite of/because of those limitations. And waiting until midnight to play your turns on all those door games. It was compelling.
Contrast to a modern social media platform where you're just perpetually bombarded by mountains of shit... because they can.
I'm also from this era and I miss it so much. That being said, I used to read old Phrack issues and felt like I had missed out on the "real" golden age of BBSes. Everything already felt too complicated by the 90s and too locked down.
That being said using BananaCom with ZModem and running my own BBS on Spitfire then WWIV, was peak computing for me.
When I switched from the BBS to the modern web+newsgroups in 1998, I immediately missed the former.
The "modern" Internet is better for finding information and downloading files. Email is better for 1:1 communication. For everything else, the BBS experience was superior.
Playing door games was better than playing online games. I'm not competing with the rest of the world!
Conferences vs forums/newsgroups: At least the ones I was part of had very strict moderation policies.[1] Discussions were always civil. Spam didn't exist.
And yeah, I miss QWK readers (heavy OLX on DOS user). For a number of years I had a QuickBasic executable that would convert my (downloaded) email inbox into a QWK format. I would read and respond via OLX, and then had some mechanism to convert the responses back to text so I could upload to the mail server.
[1] You were required to use your real name. The sysops enforced this.
There are a couple of well-supported Telnet programs you could use. A common one is SyncTerm which is purpose-built for the BBS scene (also is free). Zoc is another popular one, but it is more designed as a general-purpose terminal emulator (great for SSH-ing into servers). Zoc is commercial software.
ERP implementer for the past 20 years. I'm an operations specialist rather than a manufacturing specialist, but do have manufacturing clients whose systems I have helped implement and continue to support alongside our manufacturing specialists.
I will preface this by saying that my initial thoughts are based solely on the website and documentation (which is fairly sparse and includes few screen shots or examples of how the software is actually used). I did not and probably will not* sign up or install this software to review further, so I'll fully admit that I'm probably missing a lot and likely not giving a completely fair review.
My first impression, looking at the documentation for the system and how some of the actual ERP-related functionality is described, is that barbinbrad is an expert in software development with a lot of experience writing software to support ERP systems, but has a fairly narrow understanding of how all of the functions of an ERP system are supposed to work. To use a tired old analogy: this can be likened to a highly-skilled heavy-duty mechanic and a veteran long-haul truck driver deciding to start their own trucking business. Between the two of them, they know a ton about the mechanics of driving and maintaining large tractor-trailors and may even know how to keep proper driving and service logs and how to train apprentice mechanics and new drivers. But their knowledge on all the other minutia of running a trucking business is just enough to give them false confidence that they know the industry. Without seeking outside help, many of these startups fail because of mistakes made on these details.
There is a lot of detail on how to set up the technical parts of the system (there are definitely two things that are abundantly clear: the database back-end is postgres and the software is open source), there is some good developer-related information on API calls and such. But the documentation on how it all works is very sparse and the functionality that is described appears very rudimentary. Accounting functionality is very simplistic (limited chart of accounts definition, unclear link between subledgers and the G/L, no apparent EFT functionality, limited multicurrency/revaluation capabilities). Similarly, inventory, purchasing, and sales appear to be similar in capability to a basic Quickbooks system. A couple of more advanced manufacturing-specific features like MRP and routing/scheduling seem to exist, but MRP will only "suggest" order - users still have to enter them manually in the system, and it is unclear whether there is any linkage with general inventory planning or sales forecasts. Basically, it looks like the software can build a BOM, and it can help run most of the assembly steps for that BOM, complete with some very strong traceability and visual cues, but all of the other business functions surrounding that BOM are very limited.
To be clear, this is not meant as a direct criticism of barbinbrad or the software itself. The software has potential, and barbinbrad appears to have a lot of experience working on manufacturing ERP systems. What is needed is more guidance from people with the expertise on the "other side of the keyboard". Preferably people who have worked in ERP systems across multiple manufacturing industries.
This a huge example of a classic problem that plagues many (if not most) "non-tech"* open source projects. Developers who are immersed in a specific type of software can see what it is they're developing and get a very good idea of what the software does and how it works (according to the specs that they've been working on). So they go about building what they see as the "better version" of what they've worked on before. In the process, they often do solve some of the glaring individual problems they've encountered in the past, but they do so without understanding the bigger picture of what the system as a whole needs to do. ERP software especially is hard, because it is very complicated, used in many different ways (even by companies in the same industry) and have to support so many different facets of a business. The experts are not developers. They are accountants, operations managers, procurement and warehouse managers, production managers, payroll managers, and the C-Level executives who consume the information that ERP systems spit out. The people guiding development have to have expertise in these areas, not the developers. And in the open source world, this is where the subject-matter expertise is often lacking.
(couple of footnotes):
I'm not prepared to enter my credit card number to try it out, don't have the time to install it in my own environment just for a review, and already am a bit annoyed that I had to enter my work e-mail address just to get to the point where I realized I'd have to do one of those two things to get anywhere.
*By "non-tech", I mean that the audience for which the project is intended is a non-technical audience - ERP systems, despite being very sophisticated software with a lot of server infrastructure involved, are systems meant to serve very non-technical people.
thanks for taking a look. very good read of the state of things. Netsuite level accounting and mrp v2 are what we’re building now. We focused on running a manufacturing business from an “everyone else” perspective first.
I think you’re right in a sense that we’re building the thing I would have wanted — and you’re also right in a sense that there are people out there that know more than me. The key is to learn from them.
> A clear majority on a clear referendum question would create an obligation to negotiate.
To be further clear: it would create an obligation on the Alberta government to negotiate. A provincial referendum creates no such obligation on the Canadian government.
reply