The standard position for graphics card has been horizontal, for many, many years. I don't think the standard position for a cigarrete lighter is upside down, to begin with.
Next, for your "solution" to work you need a special case that allows for the card to be installed vertically, which is not common.
Too opinionated advice on an even worse medium. Please do yourself and the rest of us a favor and open a blog. Reading an article about watercolor basics which is basically a wall of text without a single picture is a pita.
Also some of the advice is just plain wrong. Paper should be the number one thing you shouldn't skimp on and yet you recommend buying cheap/on sale.
It isn't horrible advice: Good paper is expensive and if you can buy it on sale, you most definitely should.
And while good paper will absolutely make it easier to learn, it doesn't need to be the best paper. Just understand that the cheapest paper is usually worthless and that the next step up will cause a few struggles. I'd rather have cheap paper than bad brushes, though. (I learned on thin paper, some of it cheap)
I've used Graphviz for many years and my main gripe with it is the lack of customization. Yes, there's "some" customization, but there's a point (not too far from the initial style) where, if you don't like the output, you're out of luck and might as well redraw it using draw.io or some other WYSIWYG editor.
Graph viz is admirably powerful, even here. The main techniques seem to be invisible objects and custom code, in case that helps. The cassowary solver group in Australia (I'm blanking on the university, Monash?) goes further via custom constraint logic, and I believe iOS layouts were deeply inspired, and maybe even had one of their students.
Graph technologies are tricky to build up -- you can go deep in many areas like this. Afaict, AT&T/Bell Research used to be the main developers of graphviz, and when that corporate lab thinned out, so did graph viz development. A similar story happened with gephi devs when they left their universities (was popular in social data), and cytoscape (popular in bio) is still largely at that fragile state.
We are historically big contributors to OSS at Graphistry, but saw the history of funding issues in this space, and how each tool reached a frustratingly low ceiling due to it. We decided to not start as open core, and instead made a free GPU tier + release individual pieces as OSS (Apache Arrow's JS tier, etc) + initially charge for GPU code, until we could build + grow more commercially targeted parts. Thankfully, we are getting to the point of enough sustainable revenue that we are pushing much more to our OSS libs now, and one of our OSS pushes for 2022 will be moving custom (GPU-accelerated) traditional layouts & AI layouts to the OSS lib pygraphistry :) A request we get often get for pygraphistry and our file uploader UI is dotfile (and graphml/gexf) conversion/ingest for then viewing+editing in our scalable interactive graph renderer, so we have been thinking of adding a pygraphistry example just to demonstrate the OSS flow!
I considered OBS a really nice piece of software, specially after a 10-year long track record of testing desktop capture software like Camtasia and the like. After fighting myself with ffmpeg (libav) to build a simplified desktop capture software myself, my appreciation for OBS has increased even more, because dealing with libav or anything multimedia is definitely a pita.
> Unfortunately some are also moving to entirely closed source platforms like Discord
From an openness point of view, yes, that's unfortunate. But discord channels are arguably way more useful than IRC nowadays. The mere message persistence is something that tips the scale in favour of Discord.
Moving away from IRC means a lot of more casual open source types will not follow. I not going to install some random chat app I'm never going to use again and go through signup bullshit just to see if there's someone who can give me a hand on something - to big of a barrier.
Discord works perfectly fine as a simple webpage with a basic email/password user account. In that sense it's actually significantly more accessible than IRC, which is not web-native and does require the use of either a client or some web bridge.
It is friction. No matter how little you think it matters, adding friction always loses people. In this case, they're the old-hands types; if you think your project would benefit from losing those in favor of newbies, sure, you can make that choice.
Like I said, messing around with someone's email verification nonsense probably with a captcha and stupid questions on top is likely more than I want to spend on seeing if someone who might help me with a transient issue is even available, so I am unlikely to do so.
> Discord works perfectly fine as a simple webpage
It has a webapp, but it does not work "perfectly fine" in my experience. The UX is bewilderingly complex; it took me several minutes to figure out how to make it stop ringing more bells and whistles than a las vegas casino. I had a hard time even figuring out what symbols were meant to be buttons that get clicked; even finding the settings screen was a pain in the ass. It's truly awful.
Formerly xchat, now hexchat. I also leave weechat idling in a tmux session.
My take on discord is that it's been designed for the zoomer/gamer demographic; the sort of people who also get sucked in by gacha games. Lots of sounds and colors that leave the user dazed and intoxicated.
I think Zulip is a good alternative. It's FOSS and has persistance and threading. I do dislike the fact that you have to sign up and can't see the discussions without it.
Machines that can't run Matrix is a pretty small subset. There's a Matrix plugin for Weechat, so you should be able to connect from anything with roughly the power of a Raspberry Pi. Probably slightly less than that; but yeah, you're probably not going to have a good time trying to use an ESP32 as a client. I don't see that as a huge drawback.
Currently playing with Matrix a bit and I have to say that most of the TUI clients are pretty terrible still. The desktop clients are not much better, they either have mobile UI but on desktop or are quite buggy still. And what they all have in common is that they are quite slow as well, despite local homeserver running off an nvme ssd.
None of the ones I have tried come even close to UX of pretty much any desktop IRC client.
That had some weird interactions with some of the other scripts I was running. There were some known incompatibilities that were still being worked on - and now it's being rewritten in rust?
In any case, I wasn't having a great time with the python version of it.
So went with a more native TUI application (gomuks) and didn't really enjoy that either (scrolling broken, weird mouse behavior, unread messages got stuck on some channels and in other rooms it didn't show any unread messages at all, stuck room that I already left and some other issues that annoyed me).
Then I thought I give some desktop applications a go (quaternion, spectral, nheko, mirage and last I tried was neochat) and they fell into roughly two categories: ok-ish UX but too buggy to be usable or work but have UI designed for mobile but on desktop (which is a no-go for me).
That's where I am with my quest for a decent matrix client.
I haven't tried _all_ desktop clients yet, but there are not that many non-electron/browser based ones left I think.
It really doesn't. The best option is weechat-matrix, but that's already a dead project. The lack of good client diversity is what is holding me back from using Matrix.
Dead is overstating it. The maintainers are moving new feature development to a Rust rewrite, weechat-matrix-rs, but still accepting bugfixes/etc to the current Python codebase
Hmm. Given we got here by talking about people who can't (rather than won't) run heavyweight GUI clients, a Rust rewrite seems like it misses the point.
That is, I'm sure it makes sense for them, and for most of their actual users, because Rust is nice, but if I have an m68k machine, too bad, there is no Rust for m68k (unless I'm reading the platform support chart wrong) and so this rewrite likely orphans me.
Now, if for a Debian channel, even a Debian channel about an attempt to port Debian to m68k, then I have no doubt your users all have something less stupid, maybe ARM or x86-64 or even PowerPC. They prefer a non-GUI for their own reasons but ultimately Matrix is an option.
But if you're a channel for actual m68k "classic" Amiga you might actually have a non-trivial number of users for whom "it doesn't run on m68k" is a showstopper. They have an IRC client today.
Rust doesn't target barely-capable archaic platforms like Motorola 68xxx or 80286 and I don't think it should start. But that means we have to accept that a Rust client won't support those platforms.
weechat-matrix is really not a dead project. the maintainer works for Element, and is working on matrix-rust-sdk (and thus weechat-matrix-rs), but weechat-matrix is alive in well and in no way unmaintained or dead.
Okay, but I'm not going to go through the effort of setting up weechat-matrix if I know I'm going to need to later throw all that effort away and switch to weechat-matrix-rs. I'll just wait for the latter. It is, for my purposes, dead.
It's an example on the trivialness on using it, you can get a client anywhere, like gopher.
SSL/TLS is broken and you need help over IRC? No problem. Your main PC broke and all you have is a 486/Amiga/Atari or even some PDA connected to the router with a gateway? No issues again.
You just have a installed base, your pkg manager is broken and all you have is netcat, a shell and Unix utilities? Go on.
>SSL/TLS is broken and you need help over IRC? No problem. Your main PC broke and all you have is a 486/Amiga/Atari or even some PDA connected to the router with a gateway? No issues again.
>You just have a installed base, your pkg manager is broken and all you have is netcat, a shell and Unix utilities? Go on.
I understood what you meant. But when would any of those scenarios occur and you don't have your phone, and thus access to Matrix/Discord/whatever?
IRC has awful UX on a phone, and I say this as a guy with a sophisticated weechat+Pushbullet setup going on. The benefits of being able to get on IRC from your NetBSD toaster aren't really benefits at all because you always have a phone. Users want slack/discord-like presence. They want push notifications on hilights. They don't want to have to futz about with znc or tmux+irssi.
IRC failed to keep up with the tastes of modern users and that's why it's been slowly hemorrhaging users for 15 years.
Huh? Pretty much all mobile irc clients have that though?
And if you are running weechat anyway, something like weechat-android might be an better option for you? That connects back to weechat using the weechat relay protocol.
>Pretty much all mobile irc clients have that though?
Sure but the connection drops a lot if you roam, if you close the app you don't stay connected, etc. Discord does not have this problem.
>And if you are running weechat anyway, something like weechat-android might be an better option for you?
You're missing the point. I already run weechat-android but it's not about me. It's about people who have grown up accustomed to more modern and mobile-friendly applications. If the only way to get multi-device sync with push notifications is to run weechat in a tmux on a shell and install/sign up for Pushbullet, that's awful UX. Too much friction, to say nothing of the idea that the best way to use IRC is to sign up for a third party shell account.
I hate discord but it's a breeze to onboard people to your server.
> Sure but the connection drops a lot if you roam, if you close the app you don't stay connected, etc. Discord does not have this problem.
Yeah that mobile networking is completely broken is a bit unfortunate.
But at least the staying connected in the background part works just fine for me (Also works fine with my jabber client).
Not sure why you still need pushbullet if you are already using weechat-android though (and not saying that I would recommend that for everyone.. something like IRCCloud is more suitable for non-technical people I would say).
Or is it weechat-android specifically that has the problem of not being able to run in the background for you?
Weechat-android might not drop because it's a relay client. But try running a non-relay client and see how it goes.
Anyways it's like you're intentionally missing the point. I'm not here for tech support with my setup. I'm trying to explain why IRC's user experience is inferior to Discord for most users.
I tried with a normal IRC client on Android. And like I said it also works with my Jabber client, which I have been running for years now and never had problems with missed notifications or anything there, despite it also requiring a open TCP connection to work.
The only thing is it's less nice for the _other_ irc users in the channels if they don't have filtering setup to get rid of those extra joins/quits if you are in a bad connectivity area (unless you are running a server that itself hides them).
But for onboarding that makes no difference at all.
However the sore points come a bit later with most servers having no server-side history, integrated bouncer, etc. (which would all require a bouncer or tmux+weechat, which I totally agree is not for everyone)
If you want all that you are limited to exactly one ircd currently (Oragono) that has integrated bouncer (so no need to run weechat/znc to stay "connected"), server side history (same history on all your devices and also not loosing anything on disconnect) and multi-session support (being online with multiple clients using same nick).
Some of those features are slowly diffusing to other ircds and from there to irc networks, but that takes time.
That only solves half the problem. There's no easy (read: 1 click) way of quoting an older message. No easy way of handling notifications (read: not PMs but when someone mentions you in a channel like @handle in other chat services), no easy way of handling roaming, etc.
Yes, ZNCs solve some of these problems, but they're not easy to set up, the channel mentions isn't even remotely as intuitive as that in Slack et al and the playback history isn't as user friendly as the history in other chat services because it replays _n_ messages irrespective of whether you saw them or missed them while DCed. Which can make roaming a PITA at times.
I say all this as a someone who loves IRC. I've built IRC clients in the 90s, numerous IRC bots, ran ZNC services and even use IRC as my primary IM back in the early days of Android (and thus seen first hand the frustrations of using IRC on the train and getting frequent disconnects to my bounce).
IRC as a concept is amazing however IRC as a protocol sucks by modern day standards and while all the little workarounds are fun to hack together, ultimately they still fall short of what products like Slack and Discord are doing. So I can totally see why some people don't bother with IRC any more.
I've not (yet) played with Matrix. Maybe that's the spiritual successor to IRC. It sure as hell can't be any worse than XMMP (I _really_ wanted to like XMMP but just couldn't get past how unnecessarily over-engineered it was)
Sorry just seen this. It's been a long time since I've touch XMPP so I might get some of the specifics wrong, but IIRC it was XML heavy. Everything was an XML file. Every message. I know XML will have it's fans but for an instant messaging app that create a hell of a lot of overhead. But in fairness to XMPP, it was created in the era when XML was basically the go to if you needed a strict schema.
Joining to servers was a pain as well. XMPP was intended to be federated but in practice it didn't really work well. A large part of that reason was because XMPP described a base protocol but then different servers could support different extensions off that and if your server didn't support the same extensions then you couldn't join. These extensions could vary from the "well that should have been part of the base standard to begin with" to the absurd.
There was also a lack of decent clients for XMPP. To be fair, this isn't XMPP's fault but rather the lack of adoption. But because XMPP was something that Google or others would use as a base to build their own IM network from, all of the good XMPP clients were locked into specific networks rather than like with IRC or Matrix clients that are designed to run on any network.
A lot of the tooling for XMPP wasn't particularly noob friendly either. It was very much built by engineers for engineers rather than intended for your average nerd to set up a private servers. I remember one XMPP daemon was written in Haskell and all the config was hardcoded so you had to edit Haskell source to bring the server up. Which isn't the easiest thing to do given how alien Haskell looks to non-Haskell developers.
> IIRC it was XML heavy. Everything was an XML file. Every message. I know XML will have it's fans but for an instant messaging app that create a hell of a lot of overhead.
The "overhead" is minimal, especially with the features XML brings. A message looks something like:
In a world where people stream HD video over their mobile data connection without a thought, I'm pretty sure XML is not an issue. There are binary bindings (EXI), but they never really took off outside some niche IoT systems. It just hasn't been a problem. XMPP has even been deployed over unreliable high-latency HF radio links: https://www.isode.com/whitepapers/naval-xmpp-roadmap.html
> Joining to servers was a pain as well. XMPP was intended to be federated but in practice it didn't really work well.
> A large part of that reason was because XMPP described a base protocol but then different servers could support different extensions off that and if your server didn't support the same extensions then you couldn't join.
This isn't quite accurate. Every extension in XMPP is designed with backwards-compatibility in mind. Two servers not being able to federate is not really a thing - federation is in the base protocol. On top of the base protocol various things can be negotiated. None of these are mandatory. Two servers not being able to federate due to differing extensions is a myth.
> There was also a lack of decent clients for XMPP. To be fair, this isn't XMPP's fault but rather the lack of adoption. But because XMPP was something that Google or others would use as a base to build their own IM network from, all of the good XMPP clients were locked into specific networks rather than like with IRC or Matrix clients that are designed to run on any network.
For the record Google federated with the open XMPP network, and allowed third-party XMPP clients to connect. Other providers of XMPP were not so open (Facebook never federated, for example).
Opinions of what constitutes a "decent client" vary widely. Being an open ecosystem, XMPP has a wide and diverse range of clients, and many people quite happily use modern XMPP clients such as Conversations, for example.
The biggest problem is that most clients are "just" open-source projects backed by volunteer efforts. It's very hard to find real sustainability (e.g. funding) in open-source, let alone open decentralized ecosystems, so resources are more limited compared to proprietary competitors.
> It was very much built by engineers for engineers rather than intended for your average nerd to set up a private servers.
I don't know which Haskell server this was (surprisingly), but I've been working on making XMPP server setup easier since starting the Prosody project back in 2008. More recently I'm also working on Snikket, which takes things to a whole new level - you can have a private XMPP server up in just a few minutes without any technical knowledge of XMPP: https://snikket.org/service/quickstart/
> The "overhead" is minimal, especially with the features XML brings. A message looks something like:
Yeah, something like that. Just with a hell of a lot more metadata and closing tags to accompany it. I'm all for strict schemas and the first to criticise IRC's protocol for being dated, but XMPP is an overreaction. It's too far the other way. But I do get why XML was chosen -- frankly there wasn't any better options in 90s. But that still doesn't mean it isn't noisy and the, in my personal opinion, wrong choice.
> In a world where people stream HD video over their mobile data connection without a thought, I'm pretty sure XML is not an issue.
Smart phones weren't invented when I was running XMPP and the kind of bandwidth you're boasting about is a very recent development in the grand scheme of things.
> The large active network of federating XMPP servers would disagree with you.
That's also a recent development. Plus look at the graphs: even now it still hard to argue that you're even close to reaching that same kind of critical mass as the major IRC networks currently have (let alone had in their heyday) and that's without addressing the elephant in the room that is Matrix and it's far steeper uptake climb than XMPP. I mean, sure, you have a small and loyal fan base but chat protocols depend on that critical mass in the same way that social networks do and I can't see XMPP ever achieving that because it's already missed its opening.
It's now 10 years too late to be talking about XMPP and yet that's when all the advances you keep bring up were started. The protocol was already > 10 years old at that point and many engineers like myself had tried it and given up.
> Two servers not being able to federate is not really a thing - federation is in the base protocol. On top of the base protocol various things can be negotiated. None of these are mandatory. Two servers not being able to federate due to differing extensions is a myth.
Maybe now, but I never managed to get it working properly ~15 years ago. It might have user error or such like but I'd ran private IRC networks, bounces, written 2 different IRC clients, a multitude of bots for different chat services (ie not just IRC) and run a whole plethora of other internet facing services and literally the only thing I could never get working quite right was federated XMPP. So I have a tough time accepting total blame for not getting it right.
And the shear that you can call it a "myth" suggests enough other people ran into the same or similar problems as myself for it to become a problem that people talk about in the first place. Which adds weight to the argument that perhaps it's not entirely fair to blame the users.
> For the record Google federated with the open XMPP network, and allowed third-party XMPP clients to connect. Other providers of XMPP were not so open (Facebook never federated, for example).
Yes I know. And for the record, you're literally making the same point I made.
> Opinions of what constitutes a "decent client" vary widely. Being an open ecosystem, XMPP has a wide and diverse range of clients, and many people quite happily use modern XMPP clients such as Conversations, for example.
Once again you missed the part where I mentioned it was a long while ago when I used XMPP.
> I don't know which Haskell server this was (surprisingly)
Me neither. tbh I can't even remember which hosting provider it was I was renting rack space from, it was that long ago.
I'm glad to see the state of XMPP has improved somewhat. But it's too little too late now because the industry has already moved on.
Kids these days, who should get off our lawns, do not like that user experience.
If I was starting a new chat channel for a project, I'd use Matrix, not IRC. Matrix is more decentralized than IRC due to federation, and Element offers a user experience that should be familiar and comfortable to users of Slack and Discord.
Maybe I am alone in this, but not everyone likes the UX of slack or discord and might prefer a more information focused/less distracting desktop application and prefer a native desktop application over something electron/browser based.
And for those people the current options for Matrix are all very much a work in progress to put it mildly.
I've been using nheko (well, the fork of it that's actually maintained). There are a couple areas in which it's a bit of a WIP, but it's a pretty good experience so far.
Giving Nheko a spin right now and while it is somewhat better than some of the other matrix clients I have tried, the UI is still much too close to discord/slack for my taste. And doesn't have enough knobs to disable features I don't want(*) (hopefully that will change over time). It feels quite a lot snappier than the other clients, which is good.
It wastes quite a bit of vertical space per message, but it's still somehow hard to see for me which lines were said by which person. Something with relative placement of avatar, nick and message is throwing me off.
(*) Granted, it may be a bit odd that I simply want to disable _all_ matrix features (avatars, replies, displaying images, honoring redactions, large multiline messages/embedded texts, typing notifications, etc.).
There's more than one way to do it, and I definitely look forward to clients becoming more varied and configurable as Matrix (I hope) grows in popularity.
Totally agree that not everyone wants the same UX.
And same applies to IRC as well, there are clients that go more in the slack/discord direction (which I also won't touch), but it's great to have options, so everyone can be happy in the end :)
> If I was starting a new chat channel for a project, I'd use Matrix, not IRC. Matrix is more decentralized than IRC due to federation, and Element offers a user experience that should be familiar and comfortable to users of Slack and Discord.
I've been trying Matrix on-and-off, and found it ridiculously complicated to figure out bridging (which is probably Matrix's top selling point, and was important for my communities) on the "official" servers.
Given how some (open-source-esque) communities work, there'll be people who prefer using their preferred platform (e.g. IRC, Discord, Telegram) even if it doesn't have first class support.
I hope they have (or have plans to) updated the docs for their plugin API. I've made some bucks building plugins for ST3 and the docs are... scarce. It's a shame, because I prefer using Python for building plugins than JS or TS as in VSCode, but it was a PITA to find anything.
Totally. Not sure about the US, but at least in Spain that kind of benefits (private health insurance, restaurant tickets, etc) tend to be a lot cheaper for the employer often just for being a company, but usually for the large quantities they work with.
+1, thank god we've finally come to acknowledge and accept that Gimp has never been and will never be a professional alternative to Gimp for many users.
Would you mind commenting on your current salary range and location? I've decided I want to stick to C++/Python on Linux for my tech stack, as I've grown to hate the current state and pace of web development.
Next, for your "solution" to work you need a special case that allows for the card to be installed vertically, which is not common.