• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Wiki/Pages article ideas

Cory5412

Daring Pioneer of the Future
Staff member
There's a lot to say here. Ultimately, there's three things that I think say it best:

1: I think that parsing the HTML of the old forum will be a lot harder than you think. There are a lot of issues to dealing with it. I also think that integrating it into the new forum is going to be very difficult, without, say, wiping out user accounts. Doing that also puts the "historical context" at the far back of the regular site, which is "fine" (maybe even "ideal") but I think I like it better the way it's presented now.

I don't disagree that it would be ideal if we could write our own CMS/forum/wiki/blog et al, but I think we got something pretty good with Invision, and I'm okay with the compromises that we got.

2: The reason we're going in the direction that we are is that even though the wiki is better for the ultimate task of "writing an encyclopedia" -- we have a culture on the site that prevents editing because of the poor integration with the site, visually and technically. In addition, it's more difficult to maintain both, and because they use two separate subdomains, SSL certificates cost more and the infrastructure is more complicated to configure.

If the argument is that we shouldn't have or port, say, the spec pages over, then that makes the case for using IPB even better because those are one of the most straightforward uses of tables. (Although there's some other things, such as the list of video cards, which I don't believe are fully replicated elsewhere.

3: The whole reason I posted this thread was to aggregate ideas on what would be appropriate to post in our pages. I tossed out some initial ideas, and while I think the other part of this discussion is valuable, it does take away from the idea of "what content should be on the site." (Although I do think a lot of that is that there's not an awful lot of that at the moment, which is fine.)

I can split this topic if you'd like or we can post another one on the technical issues, but I will say that for the most part, this discussion will mostly apply to whatever forum software we switch to 7-10 years from today, since our investment in this platform is sunk and we haven't even finished what we consider to be our migration tasks yet. (the images, for example, a great example of how little time we have to dedicate to things like maintaining two crusty old installations of software we didn't even install ourselves.)

 
Last edited by a moderator:

Themk

Well-known member
1: I think that parsing the HTML of the old forum will be a lot harder than you think. There are a lot of issues to dealing with it. I also think that integrating it into the new forum is going to be very difficult, without, say, wiping out user accounts. Doing that also puts the "historical context" at the far back of the regular site, which is "fine" (maybe even "ideal") but I think I like it better the way it's presented now.
My idea of databasing the information there was less about integration with the rest of the site, and more about having the data in an alternative format, that would make doing something with it easier in the future.

 

Cory5412

Daring Pioneer of the Future
Staff member
The format it's already in should be accessible on version 3 and 4 browsers, which is what we used to access the site when it was new and running that software.

The software itself the data was ripped out of should be the version we had when the site was originally installed, which was in 2001.

The SSL is another issue, and the only real way to resolve that would be to change the URL and re-configure the hosting from 68kmla.org/forums/archive to archive.68kmla.org or something like that.

For the time being, I'm presuming that's completely off the table, but once things settle down, it's not too wild a request to make. The infrastructure is already set up for multiple URLs, the DNS change is easy, the files would have to move, and we wouldn't need to get an SSL certificate for it.

 

Cory5412

Daring Pioneer of the Future
Staff member
I forget what we ended up doing, but either way it's more money. It's not a huge issue, but it does add up. (If, for example, we keep the site running another 17 years.)

I don't remember why we aren't on Let's Encrypt. Probably because our infrastructure is based on freebsd and the Let's Encrypt people actively dislike everything except for Debian and Arch linux, including anything RPM-based.

 

Themk

Well-known member
To be honest, the homepage of Let's Encrypt has "LINUX FOUNDATION" written on the top of it, it's not a huge surprise that they are anti freebsd.

At some point, if the current admins are unable to maintain the site, than perhaps a pass down to a new administration team that is capable would be good to do, continuing on the next generation of the 68kmla. Obviously that is not on anybody's radar right now, as such a thing is highly unlikely to happen in the next few years.

 

MidnightCommando

Well-known member
For what it's worth, there are now several guides on using Let's Encrypt with FreeBSD. It's not the nuisance it used to be.

https://oddball.tech/ is running on lighttpd + freebsd/ppc and uses Let's Encrypt for SSL certificates. It also plays nicely with Classilla, so that's good. 

(Don't mind the landing page, if you actually go look, I haven't got anything fancier ready for public consumption yet.) 

 
Last edited by a moderator:

Blastoise1994

Active member
Not sure if it's been mentioned yet or not, but I think hosting tutorials on how to repair and/or upgrade your Macs on the wiki could be a good idea. I'd be willing to write up a few on the G3 Clamshell.

 

Cory5412

Daring Pioneer of the Future
Staff member
Unrelated update: We (the admins) can enable or disable HTML posting per groups. I was able to add, then edit, an HTML table in an article. The markup is a little weird, but perhaps that's just new HTML.

I'll have to run this by the rest of the mods/admins, but my thought here is that either we (the mods/admins) can clean up and amend tables in articles, or we can create a user group of wiki authors/editors who have this permission. (Probably along with some other permissions, such as approving article submissions, etc.)

It's not a permission level that the software appears comfortable with allowing to everybody.

 

Cory5412

Daring Pioneer of the Future
Staff member
Dropping this in here as an article idea.





Also, yes, I know the wiki is unavailable at the moment. We're waiting for wthww to get a moment.

 

register

Well-known member
Could we probably combine the creation of a »sticky« with the creation of a stub in the wiki which links to the stickie in the forums? As written before, the wiki is a pretty good tool to write an ecyclopedia. The wiki is made to ease a lot of tasks involved into collaborative care for information of the sort we use. I am not a wiki nor a forum software expert, but I like to occasionally debug some text or to contribute some finds or thoughts. Please consider to use the best of the forums and the wiki, and probably nudge the userbase towards sustainability of useful information :)

 

Cory5412

Daring Pioneer of the Future
Staff member
Networking idea: what network interfaces for 68k/ppc mac require the use of special connection equipment



In the context of Von's thread, what network adapters are incompatible with switch ports or 100+megabit Ethernet ports?

As a baseline, to the best of my knowledge, all onboard Mac Ethernet is compatible with all modern switch ports.

 

Cory5412

Daring Pioneer of the Future
Staff member
SCSI tutorial and/or basic information about how SCSI works in general and on Macs.

 
Top