> What should you do? Phrase it better. Post your reports with the attitude that you are just one user, using free software, from the humility of your own personal experience on your own system. Make it clear you don't expect anything from the report, you are grateful the software exists, you intend to keep using it and this is your small way of giving back. Say this in words because I can't see your face or hear your voice. Write "thank you" and mean it. Acknowledge the costs in time and money to bring it to you. Tell me what's good about it and what you use it for. That's how you create a relationship where I can see you as a person and not a demand request, and where you can see me as a maintainer and not a vending machine. Value my work so that I can value your insights into it. Politeness, courtesy and understanding didn't go out the window just because we're interacting through a computer screen.
I don't want that kind of stuff in bug reports for the same reason that I don't want to have to deal with "hello", "good morning", from coworkers in messenger applications, and I will assume that for your sake you don't want to deal with it either, unless you explicitly say so.
So if this is a requirement for writing and responding to bugs, then you should "say it in words" that that's what you want.
The baseline expectation of social niceties is the lubricant upon which our human systems run. That you don't personally find them necessary, or even perhaps find them aggravating, does not mean that they should not be by-default valued in the recognition that the person at the other end of the line is a fellow human being with feelings and needs.
It does not take much effort to be nice in the general case. Your desire for efficiency does not supersede respect for others' humanity. And, frankly--resentment at a coworker for saying "good morning"? Yikes.
There's a difference between having niceties and content in one message:
> Good morning! When I foo the bar, I expect it to baz, as per documentation at <link>, but it seems to be drizzling instead. Could you please tell me if it's me doing something wrong, or there is a bug in bar that prevents me from fooing it? Thank you!
Compare this with the typical annoying IM exchange that happens across multiple timezones (EU ↔ India seems to be the worst):
<Mar 01 2021 05:59> Them: Hi
<Mar 01 2021 10:00> Me: Hi, what's up?
<Mar 02 2021 04:03> Them: Do you have a moment?
<Mar 02 2021 10:00> Me: Yeah, what's your concern?
<Mar 03 2021 04:20> Them: I have a question
<Mar 03 2021 10:00> Me: What's the question?
<Mar 04 2021 04:54> Them: I'm trying to foo the bar and it doesn't work
Grrrrgggh! Four days! FOUR days pass and they are only starting to ask the damn question!
Okay. Sometimes it's not so bad. Sometimes it's only two days wasted.
There absolutely is a difference between inefficient and efficient communication, and you're right to highlight it. There is no gap between efficient and pleasant communication, though, and attacking pleasantry as if its sin is inefficiency is pretty messed up.
Like you say, that exchange is no less pleasant, and of course way more efficient, if it's one message with better information density. That takes some coaching, but the answer (and to be clear I don't think you're advocating for it) absolutely isn't "be a grouchy turd in the name of efficiency".
(And arguably that should then be an email, but most folks have forgotten that email exists, so, yeah.)
2. What about your message, or any of the other messages here, exempt them from requiring the sorts of obligatory pleasantries ("good morning"; politeness and courtesy that should be "[written] in words"; etc) that you're so strenuously arguing for as a "baseline expectation"?
(I'm going to pre-emptively call bullshit on any "giving a taste of one's own medicine" response to the latter question. I'm not interested in dishonest answers.)
Ooof, never seen it that bad, but that would be really annoying and you shouldn't tolerate it.
My rule is if the help I need isn't so urgent that it requires chat, then I'll send an email.
Also if I'm doing something in response to their request then I'll always say what I'm doing when I do it, so they at least know that their request is being worked on. Kinda like
Mav: Switching to guns
Goose: Ok
Mav: Firing!
Goose Ok, hit?
Mav: No - trying it again as sudo ...
Yeah, this is a really annoying habit in instant messangers, even without the long delays in response. I've just taken to not responding to messages like 'hi'. Either state what you want or I'm not going to interrupt my workflow to ask. (that said, I don't mind (and may appreciate) pleasentries included along with useful questions or information, even on bug reports, just don't add more round-trips for the sake of them).
"Good morning" in chat is not a pleasantry. It is a demand for the other person to switch to synchronous communication and attend to their conversation ahead of everything else the other person has to deal with. Respect for others' humanity implies respecting their time first of all.
I'll note that you didn't start your response here with pleasantries, and no one else has, either. By leaping at the opportunity to condescendingly explain human behavior, you've slipped into attacking a strawman. Take your passive aggressive yikes elsewhere.
Being delayed by a "good morning" from an oblivious coworker? More than just annoying. (Obligatory "pleasantries" from coworkers who otherwise take glee in making you miserable and obstruct you for sport? Much, much worse.) We're not friends--we're coworkers, at least nominally, and I probably have a stack of shit this high to deal with--that you may or may not be the cause of. How about this for being "nice": don't force me into dealing with your bullshit, against my wishes. Where's your recognition that I'm a human with feelings and needs?
You're unable of living in real life if you can't exchange pleasantries. It's kinda sad for some of us introverts out there, but the reality is that these things can do a lot for even simple things like job mobility in the subconscious sense. You may get mad at someone for interrupting your work for instance, but saying hello and goodbye and thank you does wonders for getting people to like you more, being able to tell someone to stop bothering you when you need it, and even in what people perceive as personality.
So you're doubling down on condescendingly explaining how to human. Cool.
Consider this: I have a high emotional IQ and acutely understand whatever lesson you think you're imparting here, I just don't have the kind of bullshit budget required in this context.
Here's the obvious consequence that no one ever seems to get, even with having it explained to them: if I'm going to have to start dropping things on the floor and make some people unhappy, guess who I'm going to choose to be the recipient? All the people most responsible for squandering the resources that were available.
Are you sure you're not dealing with a lot of burnout right now?
Your call, your problem, I've no stake in it either way. I don't need an answer here, although don't let me stop you if you feel the need. I'm just saying, is all, because the kind of analysis you're describing reminds me of the way I tend to get thinking when I'm too burned out to have realized yet how burned out I am.
Maybe I'm wrong to make the comparison, and in fact I kind of hope I am, because you sound like you're in a bad way.
Given that you felt the need to say that, you might want to reconsider whether your powers of self-diagnosis are as accurate as you previously thought.
> I just don't have the kind of bullshit budget required...
> ...if I'm going to have to start dropping things on the floor...
...then you've already failed. The goal is to never get to that point in the first place. Perhaps if you spent some of your "bullshit budget" sooner, it wouldn't have even occurred to you to make plans for throwing a tantrum.
Civility is incredibly cheap and has a multiplier effect on most other human resource metrics—such as productivity, enthusiasm and loyalty.
The remark "you might want to reconsider whether your powers of self-diagnosis" is not using "consider" in the same sense that I used it in the comment you're replying to. You are not really asking me to consider anything. You are mirroring the word choice, but the thrust of your comment is an argument that my comment is probably not true, and that it is almost self-invalidating.
Perversely, you are doing exactly the thing that the statement "Consider this: I have a high emotional IQ" is exhorting you not to do, which is to tunnel vision your way to one of the possible outcomes--the one where it isn't true--and then try to reflexively use it to justify the starting position that leads to that outcome. You are failing to consider the counterfactual.
If you can describe how what I said fits the informal fallacy of begging the question, I'll concede all disagreements, accept that you're correct in everything and donate AU$500 to a charity of your choice.
I know. I said it. Why am I having to repeat this?
> what part of your description was condescending
What? I'm not saying my description was condescending. It is a description of your reply. It pinpoints what was condescending about that reply. You are "leaping at the opportunity" to explain "how to human". This is condescending. It would be like if I launched into an explanation about why it's a good idea to shower and maintain good hygiene, as if you needed to be told that body odor can be unpleasant for other people and might make them not want to be around you.
I wouldn’t apologise. I strongly respect the social rules of hacker news but they are by no means perfect and tend to break down in the face of a well calibrated troll.
This particular variant is the verbose non sequitur anti-pattern. It’s effective because it generally can’t be identified at a glance. It requires a lot of contextualised reading. This means it gets few down votes, the canonical sign of disapproval here.
> I'll note that you didn't start your response here with pleasantries, and no one else has, either.
There are obvious differences between expressing an opinion and asking others to do something for you. Understanding that distinction makes this apparent contradiction entirely explicable.
This is the second instance of an attempt on your part to use circular reasoning so that it might be impossible to argue with you. It's clear now that you're just here for the conflict, and not (sound) resolutions. This is a dead end.
If you can describe anything about my argument which soundly qualifies as circular, I'll concede all disagreements with you, accept that you're correct in everything you have said and I'll even donate AU$500 to a charity of your choice.
> It's clear now that you're just here for the conflict
Says the person who thinks that basic, pro forma civility requires a "bullshit budget."
I disagree. Bug trackers should be respectful, and users should know that they are just one user and be humble without demanding that things are fixed immediately or otherwise showing anger/entitlement.
That doesn't mean they should write prose in their reports. Bug reports should be precise and should make it obvious what's happening to allow them to be quickly triaged and understood. They should ideally be a bulleted list with configuration, what was done, what happened, and what the user expected to happen. Logs/screenshots/etc. can be attached as necessary. It is incredibly uncommon for anything else to be necessary - and I say this from more than a decade of experience in enterprise and end user-facing software that gets thousands of feedback/bug reports per day.
As part of a triage team, I'm going through bug after bug after bug. I don't want to read paragraphs. I don't want to read your life story. I don't even really want to read your "thank you". I want to read exactly what is necessary to assign the bug to an owner and to understand its priority - no more, no less.
"All these 'thank you's and 'please's are annoyingly adding to the verbosity of the bug reports!" said no small-scale open source software maintainer, ever.
I would say that. I don't want to hear "thank you" -- I just want a clear bug report. "Thank you" often comes across as disgenuine, a plea to try to raise the priority of the bug.
I don't really know if it effects me in a major way, but if it even effects me at all, it probably would make me less likely to want to fix a bug.
Wow. I always say thank you and have never meant what you think, and it has never even crossed my mind that it could be read that way. I doubt it means what you think very often.
In a team I worked in many years ago, there was a general consensus that a manager saying "thanks" didn't come across well. It implied that the dev was doing a favour for that person and wanted to do so. Instead, they preferred something along the lines of "good work" or "great job" or similar. This indicated that the work was of value.
This was in person and in a single company, so is a bit different from issues raised by a stranger over the internet in a bug tracker.
Personally, if I don't know the person I say/write "thanks" because I mean it, especially if it's an open source project.
Thank you's are literally the only form of payment small scale open source developers tend to get. If no one cares about your project or likes it or shows appreciation then why bother with it or at least why bother responding to issues?
For some reason I always think of an episode from The Wire. Rawls is dressing down McNulty for his latest infraction and orders him to have a report to the deputy tomorrow morning, and the points should have "little dots next to them. The deputy likes dots."
Since then I always separate and mark specific items in a report, usually with bullet points. It turns out pretty often, the deputy does, in fact, like dots. But it's also important to avoid duplication.
I tend to fill my report with figures having self-contained captions. That is the only thing I expect a busy reader to read. The rest of the text is a note to self.
It won't do what I want when I click it,
So now I will open a ticket.
It should do the right thing
And not be a pain,
Would you please help me out now and fix it?
iambic pentameter or haiku? my automated bug report diagnostic tools only read prose written by the Bard, so if you choose the wrong meter, your bug gets tossed to the "won't fix" category
Write "thank you" and mean it. Acknowledge the costs in
time and money to bring it to you. Tell me what's good
about it and what you use it for. That's how you create a
relationship where I can see you as a person and not a
demand request, and where you can see me as a maintainer
and not a vending machine. Value my work so that I can
value your insights into it.
As someone rooting for [NetSurf](https://www.netsurf-browser.org/) (and any other remaining independent browser engines) to survive, I wonder if they'd be better off not supporting Javascript at all and simply focusing on good support for modern HTML and CSS, so it can at least be used to read documents. If Javascript is what finished TenFourFox, maybe attempting to support the full weight of modern Javascript and web apps is a trap. Let the big browsers try to be an entire operating system.
Ultimately I'm coming to think that Gemini may be the best hope for a simpler internet that individuals can contribute and manage.
Gemini’s standard is missing several important means of semantic tagging that screenreaders need to properly deal with content. I feel that if we are going to replace HTML, we still need to ensure that the disabled are first-class citizens from day one of whatever new standard we use.
Yes, I agree accessibility is a vital concern that needs to be fully addressed before Gemini is finalized. Here are some posts I found using this Gemini search engine: gemini://geminispace.info/
HTML already isn't meaningfully accessible. Gemini will still be an upgrade, because there's much less to spam screenreaders with, by virtue of being effectively just a hyperlinked document layer.
I think accessibility is critically-important, too, but acting like it's something required for success (however you define success) is denying the existence of the platform Gemini's already trying to supplant.
"As of 2012, 4.2 million Americans aged 40 years and older suffer from uncorrectable vision impairment, out of which 1.02 million who are blind; this number is predicted to more than double by 2050 to 8.96 million due to the increasing epidemics of diabetes and other chronic diseases and our rapidly aging U.S. population."
"Approximately 6.8% of children younger than 18 years in the United States have a diagnosed eye and vision condition. Nearly 3 percent of children younger than 18 years are blind or visually impaired, defined as having trouble seeing even when wearing glasses or contact lenses."
Any definition of success that intentionally excludes tens of millions of users (even people who aren't completely blind may need the aid of a screen-reader) is a very questionable definition.
The Web already does that. So does...all of computing! Hacker News is an English site. Billions of people do not speak English! Hacker News, therefore, has not succeeded in its goal to...be a place for sparking intellectual curiosity in English-speaking populations?
Anything is discriminatory somehow, and "We have basically a plain-text format with links" is millions of miles more accessible than HTML, computers in general, and pretty much everything in the world.
Plain HTML has a million attributes, isn't actually what any website is made of (this one even has spacer gifs), and isn't actually used in a semantic fashion by anyone (find me a page using <summary> and I'll show you a page that was sued into using it).
Gemini has two elements (link, text), and is much more accessible.
I love HTML, and I write my own sites to be accessible. I've used a screenreader, though, and can definitively say: every bit of computing sucks for the blind.
Because of the highly nested structure of HTML, it is possible to crash (from experience, with all the big names) your screenreader if there are a large number of elements, especially if there are a large number of sub-trees, like you often find in technical documentation.
HTML is accessible in theory... But in the real world, it can still be a terrible experience, unless the reader is highly optimised for streaming the HTML (not always possible), or the document is simple.
I think this is an interesting point. Now that nearly everyone uses the Internet, the bar for accessibility and the accompanying workload for implementing it is considerably higher than what it was in the 90's.
There probably weren't as many accessibility advocates back then. But accessibility is still crucial to have from a modern standpoint.
Actually, back then html was just a document format. Something to read. Alt tags were the biggest issue. Flash and js brought hidden controls and unannounced behavior trying to reproduce the native desktop controls that had accessibility build in.
For example, Gemini lacks language markup so that you can tell the screenreader to pronounce a quoted foreign word(s) in the correct language instead giving it a mangled mispronunciation in the document's default language. In HTML this is done by using span or div tags with lang="XX".
The lack of a consistent standard for Markdown is a big obstacle for this. Markdown comes in various "flavors" so you end up with a quirks mode nightmare as bad as IE6-era HTML, if not worse, and you sacrifice expressiveness as part of the bargain.
Potentially unpopular opinion, but GitHub flavored marked down is almost inarguably the de facto standard, and the vast majority of markdown in existence is GitHub flavored. We should just embrace this.
That’s a simpler solution in the sense that there aren’t many steps to get there from existing tools, but the HTTP protocol is incredibly complicated compared to Gemini, and Markdown is complicated compared to Gemini’s rich text format too.
Funny this is the second reference to Gemini I've seen on HN today after only learning about it last week. The notion that Gemini is the best hope for a simpler global scale hypermedia library that individuals can contribute and manage, not to mention actually develop clients for, seems reasonable.
For better or worse, the web is now an application development platform with two relevant implementations and zero hope of a third one arising. While not a perfect platform, its good enough. Maybe its time to accept this is what the web has become and let something like Gemini be the do-over that's focused purely on the role of globally connected hypermedia.
But if supporting Javascript kills all independent browsers, wouldn't it be better to have some alternative than no alternative?
Supporting a Javascript-less document-based web may be an alternative to creating an entirely separate ecosystem like Gemini. It's probably doomed as a compromise that pleases no one, but it might be worth a shot.
Sure, I'm definitely not going to argue against some making the effort. And I don't want to sound too fatalistic.
I just don't see a way for an alternative to be anything other than a tiny niche of like minded users. Which isn't bad in itself but it's also not really a true alternative. It's a fun extra, not a replacement.
Can I use my government's website in a noscript browser? Can I buy from online shops? Can I use social media? Can I read my preferred news site?
> wonder if they'd be better off not supporting Javascript at all and simply focusing on good support for modern HTML and CSS, so it can at least be used to read documents.
from article
> For better or for worse, web browsers' primary role is no longer to view documents; it is to view applications that, by sheer coincidence, sometimes resemble documents. You can make workarounds to gracefully degrade where we have missing HTML or DOM features, but JavaScript is pretty much run or don't, and more and more sites just plain collapse if any portion of it doesn't.
I still want a web browser that support inline images (i.e. as far as I understand, not gopher-based) but lightening fast and not running random scripts on behalf of 500 - 1000 entities. Oh, and those entities may change at any time.
I think there is room for a html browser with no js (or an intentionally limited one).
Gemini may unfortunately be the best hope in terms of what gets adoption but I feel like it swings way too far in the other direction. I see this a lot: your choices are either massively obese or minimalist to a fault. Where is the middle ground? From an engineering perspective, I think that is the most interesting area: designing something that is small and simple yet surprisingly capable. That is also what I want from software as a user.
I think Gemini goes in the "weekend project" category whereas a modern browser is more like hundreds of man-years. I evaluated Gemini, wanted to like it, almost like it, but I think it just doesn't allow me to do what I want to do. It is too simple.
I think it should be possible to design something that is more flexible, yet for which a competent programmer can write a basic client implementation in a few weekends (with some features missing but the client still being entirely usable), make it feature-complete in an additional dozen weekends or so, and also add & finish all the extras and fluff and polish over the remaining year. From there on it's maintenance and bugfixes and minor features which can be worked on as a hobby by a small group without having to devote all their lives to it. These projects are also small enough that if someone's not happy, they can fork and customize (and still be able to "keep up" with whatever developments might happen in terms of standardised functionality).
How would you propose achieving a middle ground? Anything in the middle will still have to have a lot of features, and once you have a lot of features, how do you hold the line and prevent people from adding more features until it is just the absurdly complex modern web-as-operating-system again?
The reason Gemini is so simple is not simply to keep it simple enough that anyone can write their own client or server, although that is certainly one goal. A big reason it is so simple is a general policy of rejecting new features, and that minimalism may be necessary to prevent scope creep.
If you think scope creep is an inevitable consequence of not making a protocol non-extensible, I have a thousand RFCs to show you..
Really you just need to outline some goals and rules and have the right people at the top calling the shots. Plenty of things are designed and developed with a conservative mindset where adding new features has to be very carefully justified.
I'd also like to point out that it's worthwhile to think of the complexity of all the systems you require, and not just one protocol/document format. Gemini may be simple, but when it is too simple, you will need a different protocol or format. So now you have two, with somewhat overlapping functionality that you can't merge if you insist on keeping everything absolutely minimalist. Only two isn't going to be enough.. so if you're willing to do what you do, complexity is inevitable, whether it is in a single protocol or spread across a clusterfuck of dozens of protocols.
Again, it is good engineering and good abstraction to find a solution that gives a lot of bang for buck, i.e. is reasonably simple yet covers multiple bases.
I sort of wonder how hard it would be to use Babel for your JavaScript engine: implement ES3 or ES5 and then just use Babel to transform incoming JS to what you support.
It doesn’t solve the API problem directly, but many APIs have decent polyfills.
My point is that they should not even attempt Javascript support, I think they should just drop it completely and focus their limited development efforts elsewhere.
This is pretty indicative of the ability of anyone besides a fully staffed dev organization to maintain a web browser that can browse modern sites.
I hope that the only people who are able to put in the effort to implement the ever growing web standards have good intentions and will not muck up what is quickly becoming too important of a communications medium for all of humanity.
Congratulations on such a long and successful run for TenFourFox. It’s a great project and losing TenFourFox will certainly spell the end of 10.4 daily driving and the many G4 machines which cannot be upgraded further. To me it is a testament to TenFourFox’s capability.
I just wanted to chirp a "Thanks" here for all the work you've done to keep gopher going. I'm a daily user, have a small presence, and your work as an ambassador and steward of the protocol is greatly appreciated.
I never intended to be the de facto BDFL for Gopher, but it sort of ended up that way. Still, I'm glad to see others appreciate its unique qualities and find it useful.
I've been really enjoying Gemini, and I don't think it would have happened without the resurgence of interest in Gopher. I want to make sure Gopher survives for retrocomputing, so that Gemini doesn't feel compelled to support the full weight of backwards compatibility for computers pre-dating the Web, and Gopher doesn't feel pressure to extend and update for modern needs (like privacy in a world of total surveillance). We need both, I think.
I've got a G4 "arm-lamp" Mac that I occasionally boot up for fun, and it runs TenFourFox quite nicely. I have appreciated the project and had no idea it was the effort of a single developer/maintainer. Thank you.
There certainly are other contributors, but it's largely me. Thanks for the kind word. I have a 1.25GHz 15" iMac G4 myself. A beautiful form factor which deserves to be revived.
Thank you for TenFourFox! As recently as last year I was still regression testing my code against TFF on a 12” PowerBook because it’s still my favourite hardware. If anyone ever used Bandcamp on a PPC Mac, they also have you to thank :)
I recently picked up my retro computing hobby again after selling off my collection in 2015 - when it was still all WaMcOm and the original browsers. I was happy to find TenFourFox, Leopard Webkit are able to at least support the loading of modern webpages. But it becomes very clear how much the web has changed and evolved, and even machines that I used to consider be super-fast now crawl and grind when confronted with a modern webpage.
I hope pages like Oldweb and the recently posted 68Knews will keep the old machines somewhat fun to use - other than retro gaming and general exploration.
A heartfelt thank you Cameron, TenFourFox has kept my Pismo 7410/550 alive and useful for another ten years after Camino's sad demise. I've gotten so used to the regular TenFourFox updates that I already feel withdrawal symptoms now. It's always been mindboggling to me that you've done all this almost single-handedly.
Using TenFourFox, Classilla, and the recent gopher revival have completely renewed my interest and love for my old pre Intel Macs. They have brought much joy to my life over the past few years.
> Nowadays front ends have become impossible to debug by outsiders and the liberties taken by JavaScript minifiers are demonstrably not portable.
I'm very surprised. What are the ways these JS minifiers are producing unportable JS? Do minifiers just remove white space, shorten variable names, and some may do some dead-code-elimination and inlining? How can JavaScript be non-portable?
> Writing and maintaining a browser engine is fricking hard and everything moves far too quickly for a single developer now. However, JavaScript is what probably killed TenFourFox quickest. For better or for worse, web browsers' primary role is no longer to view documents; it is to view applications that, by sheer coincidence, sometimes resemble documents. You can make workarounds to gracefully degrade where we have missing HTML or DOM features, but JavaScript is pretty much run or don't, and more and more sites just plain collapse if any portion of it doesn't. Nowadays front ends have become impossible to debug by outsiders and the liberties taken by JavaScript minifiers are demonstrably not portable. No one cares because it works okay on the subset of browsers they want to support, but someone bringing up the rear like we are has no chance because you can't look at the source map and no one on the dev side has interest in or time for helping out the little guy. Making test cases from minified JavaScript is an exercise in untangling spaghetti that has welded itself together with superglue all over your chest hair, worsened by the fact that stepping through JavaScript on geriatic hardware with a million event handlers like waiting mousetraps is absolute agony. With that in mind, who's surprised there are fewer and fewer minority browser engines? Are you shocked that attempts like NetSurf, despite its best intentions and my undying affection for it, are really just toys if they lack full script runtimes? Trying and failing to keep up with the scripting treadmill is what makes them infeasible to use. If you're a front-end engineer and you throw in a dependency on Sexy Framework just because you can, don't complain when you only have a minority of browser choices because you're a big part of the problem.
I really liked reading this. I never used TenFourFox (no Mac user at all) but occasionally came across its blog posts because it is in the planet.mozilla.org RSS feed.
I really liked how the motivation and problems for a (hobbyist) OSS project of this scale are written out.
This made it an interesting read for me - I'd say for actually almost anybody somewhat related to unpaid FOSS.
On a second note it is a shame that there are no harder governmental restrictions that hardware has to be supported by its software for a certain time. So much (forced!) waste on resources because the manufacturer wants to sell its next-generation... There are a lot of phones - still good enough hardware - but you cannot get updates for it after 3 years...
There is still hope for old ppc macs. Void Linux ppc is being actively developed and gives you access to up to date software while still being lightweight.
https://voidlinux-ppc.org/
Modern browsers seem to be somewhat over their technological skis, so to speak. Next gen browser requires next gen runtime requires next gen library requires next gen compiler requires next gen system, etc.
This is a great project. My ex still relies on it on my old 2007 MacBook. I know she should upgrade. But for some people a computer is just something you use once a year to update your CV or something.
But I understand it can't be supported forever. Thanks for supporting it as long as you could!
PS: I know many people that would be interested in old computers would also block tracking. I certainly do. So you won't see the entire userbase in the stats.
Thanks. Yes, I'm sure there are more than ping the server for updates, and a lot more machines that just come out occasionally. It's fun seeing others rework it to support old Intel machines even though it was never built for that. At this point, though, it's just a matter of acknowledging the wall is approaching even if we haven't hit it yet.
> and because there is no Rust support for 32-bit PowerPC on OS X
It's kind of a bummer how little support there is for 32-bit PowerPC / OS X. Golang as well has no support (though they do support 64-bit PPC).
To be honest, I didn't even realize his Javascript port had JIT support (the modern web is so slow on my eMac that I just assumed it was all interpreted).
I hope someday a similar endeavour will be attempted for macOS Mojave (which I intend to stay on because of its support for 32-bit applications, removed in later versions of the OS).
> The bug reports I liked least were the ones that complained about some pervasive, completely disabling flaw permeating the entire browser from top to bottom. Invariably this was that the browser "was slow," but startup crashes were probably a distant second place. The bug report would inevitably add something along the lines of this should be obvious, or talk about the symptom(s) as if everyone must be experiencing it (them).
> I'm not doubting what people say they're seeing. But you should also consider that asserting the software has such a grave fault effectively alleges I either don't use the software or care about it, or I would have noticed.
It sucks to get these kinds of reports when you are a solo dev who uses your own project, and you really do actively use the software and care about it.
But I feel like I've been trained over the years that the devs very often do _not_ seem to use their own software or care about it. So if a major showstopping problem happens on my machine, and it repros on my other machine, and then again on a randomly-selected friend's machine, I tend to assume it's widespread and the devs just don't care that much. (I still try to clearly state the repro conditions as best I am able. But if I can't find a system it _doesn't_ repro on, then it's hard to be specific.)
Sadly, this is probably a case where lots of otherwise-good users have been let down by shitty devs, and lots of otherwise-good devs have been let down by shitty users, and nobody trusts anybody anymore.
(Most recent irritating example: Google Sheets for Android has a 'remove' menu item in the 'Last opened by me' view, which claims (when I select a document owned by another user) that it will remove the document from view, but "Collaborators will still have access." At least the last two times I checked, this isn't true; it will effectively delete the document, for everyone but the owner. This has been the case for months at least; I believe it may have started when Google Drive switched their model to disallow "hard links" of documents. I'm suspicious about whether anybody on the Google Drive team has a very clear mental picture of what their sharing/containment model even _is_ anymore, at least for free users who don't have a "workspace". I reported this using the 'feedback' tool in the app, but I'm well aware that it will not reach anybody who cares.)
This should be part of bug reporting training.