I had the same issue with Teams a few years ago and I just switched to the browser version. Teams app was buggy anyway. No big deal.
The good thing with the browser version is rolling updates are immediate, no need to upgrade a flatpak or rpm. And if they fuck up, rollback is also immediate.
Also this is about removing the gnome x11 session package from the default install. That doesn't mean you can't run X11.
Having said that I don't know who would want to keep using X11 AND choose Fedora as its goto distro. This is a distro whose purpose is to push forward these kind of stuff, there are a number of much more conservative distros available and one could argue that if you are conservative and want to stay in the RPM/RH family you can use RHEL or a derivative distro such as Almalinux or Rocky. That is what I use on the media center computer in my living room for other reasons[1]. Back in the day someone would complain about outdated package but nowadays with tools like flatpak, podman and the toolbox this is just not true anymore.
[1] I don't power it up so often. I don't want to have tons of packages to update every time I power it up to watch a show on streaming. All I want is to be able to upgrade the browser's flatpak.
I use Slack in a Chrome tab and screen sharing works perfectly there. I don't know how they've managed to fuck their app up so much it just shows a black rectangle.
It's weird that it doesn't work since it uses webrtc for huddles. That's precisely what I had to enable in the browser to get various screen sharing websites to work.
Btw, this isn't for slack but teams: I use the website because their Linux app blows, but I actually use a totally different browser (chromium) to my main browser (firefox) intentionally. Occasionally when teams takes 100% cpu and memory for no reason, I can 'pkill chromium' without nuking firefox. So the "one less engine" argument wouldn't convince me.
Tabs are sharing the code though, because it comes from the same binary. Every electron app instead has its V8 and Blink in a separate binary that has to be loaded into its own RAM.
Why even install these web apps separately? You can even just create a shortcut for them that opens them in a separate browser window if you need that.
People have been asking for MySQL 8 compatibility for years. Since AWS is known for not giving out hints, we put a task in our backlog to start preparing for migration to MySQL 8 on Dec 10 2021. Luckily the date wasn't 1 month earlier.
They are only disallowing code execution within content script sandbox. You can still create a <script> tag with custom code. The script will be run in page sandbox. The main difference is that it won't be able to access chrome.* APIs but it could be affected by CSP.
I doubt that tampermonkey executes custom scripts within content script sandbox since a script could take over the extension itself. They should be fine.
Please note that as an extension developer I receive at least once a month a cash offer to inject scripts that track users.
... because dropbox is cross-platform, user-friendly, doesn't require use of the commandline or configuring an upstream source, has a web interface, simple sharing with others, etc etc etc etc
Those kinds of "can't you just..." or "why use [easy user-friendly popular thing] when you could [complicated nerdy feature-bare alternative]" answers are rarely helpful and typically come across as condescending.
Yes, there are complicated containerized or fancy disk volume spoofing workarounds, and there are also alternatives (I like SpiderOak), but none are as simple as using dropbox was.
I got 1 TB for free with TransIP STACK. They use encryption on their end, I use on mine as well (Cryptomator). Its cross-platform (basically their clients are a fork from OwnCloud/NextCloud), there's a web interface, simple to share with others, and it works on every filesystem AFAIK. No vendor lock-in.
The only thing Dropbox has going for it, is that it was the first one which was both easy and popular when there was demand for it. That's all. Network effect example numero uno.
That's the risk you run when you choose convenience over sustainability. If you spent some time and used syncthing you'd get something that won't just disappear some day.
I've been thinking about this attitude a lot recently, and realising how much it's holding back open source -
- since everybody said "rsync is good enough", we stopped innovating file sync tools in the 90's; and it was only when dropbox came along that we realised what we were missing, and now open-source is playing catch-up and is still behind (I'm using syncthing myself, but I still recommend dropbox to non-technical friends & family as it's easier to set up)
- everybody said "IRC is good enough", and so chat protocol innovation stopped in the 80's (except for XMPP, which was a better protocol that never really took off because the implementations of that protocol were a mess); and now Slack & Discord have come along and eaten IRC's lunch, and again open-source is trying to clone those
- "Mobile chat apps are dumb, don't bother creating one of those; you can just set up IRC on your phone, with ZNC as a bouncer on your server"... now closed-source closed-protocol whatsapp has literally billions of users, and no open-source open-protocol chat app has even 1% of that
- VNC got made the standard remote-desktop tool, and has recieved only incremental improvements since the 90's. Last week I discovered Parsec, which is simpler, faster, lower latency, higher quality, and includes sound - which are all objectively useful traits for a remote desktop system. Why did the open source community never come up with a tool that's "similar to VNC except simpler, faster, lower latency, higher quality, and with sound"? There's no technical reason that we couldn't have created that in a free and open source way a decade ago - but we chose not to, because VNC was "good enough"
Alas, I have no idea what can actually be done about this situation; and I have a minor fear that I'd be crucified for even suggesting "let's stop incrementally polishing all our 80's software, and use 30 years of hindsight to create something better" (witness all the resistence to wayland / pulseaudio / etc), but I'm open to suggestions...
One thing you keep forgetting: your polished 80s software is running the world. Not Slack, not Discord.
You can kill of Slack, no one will be less productive, have a worse work day.
Shut down something old like shell scripting, and almost every IT company on this planet will be down for months if not years.
If you want to improve, you have to start where it begins. Tech starts with small things, but not with Electron apps.
Innovate for all tech people, and thus enable fancy stuff. Make shell scripting as good as writing shell tools in go.
I am with you in terms of iteration and improvements but I get the feeling you have never had to deal with scenarios where guarantees needed to be given for life or death situations. And those are usually the reasons for things you find antiquated or odd. It's worth investigating, I promise.
> your polished 80s software is running the world. Not Slack, not Discord.
Comparing chat apps to shell scripting is apples to oranges - let's compare apples to apples:
- Discord: 130 million users
- Slack: 8 million (3 million business users)
- IRC: Optimistically 0.2 million (The best data I can find say 0.1 million, let's be generous and double that)
Given that slack has 15x as many business users as all IRC users combined, I think it's fair to say that Slack has a lot more effect on real-world productivity than IRC does.
The numbers of dropbox users vs rsync users are even more hugely different.
My point here is that there's no technical reason why we can't have great, useful, user-friendly, world-leading open-source software; but the culture of open-source says "let's focus on making shell scripting better, forget about electron apps", and the result of that is that while our developer tools are ok, all of our non-developer software is half-assed clones of proprietary stuff and we're always playing catch-up instead of leading. My worry is that attitude is making the open source community largely irrelevant in modern computing, which is going to be bad for its long-term health :/
And you have not yet encountered the backlash you get from users as on Open Source developer when you try to implement said useful, user-friendly things?
I have been at that spot various times and users almost always start unleashing hell if your next commit / PR is not that fix etc. they wait for but some general improvement for everyone.
You do that a few times, then the emails arrive, trying to coerce you into doing exactly what a very specific user wants and later threats of DDoS arrive.
Also... those nice tools are usually developed by the same open source people. They pay their salary.
If you wanted to know "can you use rsync?" (a technical yes/no question), perhaps you should have asked that, instead of asking "why use dropbox?" (a subjective preference question)?
To answer the question of "can you use rsync instead of dropbox?" - yes, it is "technically possible" to use rsync to transfer files between multiple devices.
I don't understand why you would ask this question though, because everything is "technically possible" if you ignore all the constraints that stop it from being possible...
I assume English is not your first language? If you say "X? But the real question is Y", then it's quite valid to assume that "X" was hypothetical, and the real question was "Y" :)
I was thinking the same thing. Their google search language comparison is probably incorrect. For example no one includes the keyword "javascript" when searching for nodejs or react. Instead they should have used Stackoverflow's developer survey results.
From an article that analyzes Stackoverflow's developer survey results[1]:
1. JavaScript
2. HTML
3. CSS
4. SQL
5. Java
6. Bash/Shell
7. Python
8. C#
9. PHP
10. C++
But nodejs and react aren’t programming languages. No one is including “c#” when searching for spreadsheetgear, asp.net or wpf even though they are .net libraries and frameworks.
Precisely the point. If you don't count searches for popular libraries and frameworks into their respective language buckets, the results are mostly bullshit, and at best probably reflect the undergrad curriculum.
Yeah, JavaScript also has too many names for the language itself. I mean, I search for “Django” or “Python 3” instead of “Python” half the time. But with JS, if I’m looking for info about the language itself it’s usually with the keyword “ES6” instead of “JavaScript”.
As a chrome extension developer I really like this. Previously I didn't develop extensions for other browsers because I would have to learn another ecosystem. Now it could be pretty simple to do.
I also like that all of the asynchronous API calls are returning Promises. Chrome API is still using callbacks. This also means that some time will pass while this is even added to chrome. I expect that there will be a polyfill library that translates the new API calls to legacy browser API calls.
