I think hitting the flagging threshold is probably the most tangible power as having enough accounts with that power will let you “suppress” certain topics. At least until a mod intervenes.
(Unless I’m misremembering. I think flagging required some level of karma. Or was that vouching?)
Wouldn’t that leave out the set of people who have no income? For example, long term unemployed, adults switching careers and needing to take a long time off for education, etc? While the solution gets close, I don’t think it’s strictly the same thing. Add on top of that our unnecessarily complicated tax system and this sounds even less equivalent.
Huh? I’ve been backing up my iPhone photos to my home server (running ZFS) since my first iPhone back in 2011. And Linux was my primary OS too. Not sure where that iPhone Air comment comes from.
This brings me back. My first DIY PC used an Abit motherboard. It was a great computer and was still functional after 5 years before I upgraded. I never knew about the poor quality capacitors. I guess I lucked out.
This doesn’t appear to always work? Sometimes the placed item gets sent back to the original position even though it’s clearly being placed in a new spot (at least from what I can see visually). The UX idea is nice.
> However, we've got a new CEO, and one from the Firefox side who openly talks about Firefox being the core focus for Mozilla. This is exactly what we've been asking for! I think we should give them a chance.
You know the saying “fool me once, shame on you, fool me twice, shame on me”? Mozilla is well beyond a count of 2 for me and I assume everyone else who is generally pessimistic about every new plea for giving Firefox another chance. While I understand the angle you’re coming from, I think this argument will read as disrespectful to those who have given Firefox multiple chances.
Actions speak louder than words. I think that Mozilla has to make multiple moves in the right direction before this type of plea can be made.
Yup, came here to say this. After reading the article, it became abundantly clear that the author doesn’t support Linux and most of the article is just a summary of the common Tauri talking points that are out of date. To add data to this - Tauri is looking to allow embedding chromium as an option because the creator of Tauri acknowledged that it doesn’t work well on Linux. To the point where if Linux is a serious target, they don’t recommend Tauri: https://github.com/tauri-apps/wry/issues/1064#issuecomment-2...
The upstream projects aren’t in a place to support this yet so this feature didn’t make it into Tauri v2. I’ve been tracking this for a long time and hope that they will make it possible in v3.
Thanks for the link. That's great info to know but it's only part of the problem. If they think changing out the renderer will fix everything then they haven't learned anything.
Their build action creates seriously flawed AppImages for Linux for multiple reasons that have nothing to do with the renderer but with the AppImage creation process.
Good to know. Every time I gave Tauri a shot, issues with the state of WebKit on Linux was always my first hard wall. I never got to even trying to make a production executable. Sounds like it’ll be a long time before this ever becomes viable for fully cross platform use cases.
The author addresses this too. Once you start down this path, you go down the road of non-standardization which means losing portability, etc. I don’t see how this is a point against the author?
None of the author's other suggestions are portable either. So what if pandoc markdown is only understood by pandoc's tooling? DocBook is only understood by DocBook tooling. The difference is that pandoc markdown is already 95% similar to every other flavour of markdown, so migrating to a new system (if necessary) would be relatively simple. Also, the difference is that XML is a pain to write and I'm not sure semantic tags matter all that much.
Maybe portable isn’t the right word. I read portable as meaning the format’s semantics are consistent across platforms. The way I read the author’s complaint was that once you start tacking on extensions to markdown, you run into the problem of seeing if other markdown platforms being able to support your variant of markdown. Hence the part about CommonMark vs GitHub-Flavored Markdown vs etc. Having actually run into this before when working on CMSes in the past, I get why the author sees this as a problem. I don’t think everyone will agree with the authors viewpoint, but I just happened to think that this thread is completely missing the point that the author is trying to make.
> I read portable as meaning the format’s semantics are consistent across platforms.
By that definition, a format which is only implemented on one platform is 100% consistent. I agree Markdown is uniquely fragmented, but it's also uniquely widespread.
Markdown is an extensible core for writing platform-specific languages. I think comparing markdown in general to something like DocBook is comparing apples to oranges. Instead compare (e.g.) Pandoc's specific markdown variant to DocBook.
> I think comparing markdown in general to something like DocBook is comparing apples to oranges.
Hmm let me rephrase the issue I have with the comments in this thread. If your position is that markdown doesn’t belong in the same category as the others, then yeah, I agree. But I also think that’s basically rejecting the premise of the article and there isn’t a discussion to be had. If you disagree with the core premise, then it doesn’t matter what is said, there’s no discussion to be had.
However, the original parent comment is stating that the author’s assertion is false because you can extend markdown. I don’t see how that logic doesn’t run into the semantics and “portability” problems that the author is writing about.
I think you can have the discussion, but you also have to be careful about how you have it. Markdown is a family of languages; if you want to evaluate markdown against something like asciidoc for a particular use case, you have to pick the members of the markdown family which are best-suited for that use case and evaluate those flavours individually.
Take the comparison between markdown and asciidoc. You can't say, "asciidoc has semantic structure and markdown doesn't," because pandoc markdown does have semantic structure. If you need semantics, you can use pandoc markdown, which is a very fully-featured language that suffers from none of the issues the author points out. Yes, other flavours of markdown exist too, but so what? This one has great tooling and suits your needs.
Of course, you can't use pandoc in (e.g.) Reddit comments. But you also don't really need semantic markup in Reddit comments. It's a different flavour of markdown in a different application that is solving a different problem. Or consider MDX: Yes, `Command` is a react component, but maybe it needs to be a react component. Maybe it has a "run this command" button, or it generates an interactive graph of some sort. If you mark that up in asciidoc, you need a whole separate system to attach your components to your markup. That's just using the wrong tool for the job.
Not surprised. Our one experience using Sonder was horrible. Toilet didn’t work and was constantly flushing water. Took forever to get connected to someone. Then they said that they didn’t have maintenance to send until the next day. Asked to be moved. Next room was much worse (other broken stuff, visibly poor condition) but at least the toilet worked? They didn’t have other rooms to change us to. At that point it had been several hours on the phone, so we said fuck it. We need to eat and sleep after our day of travel. Not get hot potatoed around between clueless customer support. The only other two people I know who tried Sonder had similarly shitty experiences that swore them off too.
(Unless I’m misremembering. I think flagging required some level of karma. Or was that vouching?)
reply