401 karma · joined July 10, 2010
At some point in that thread around summer 2019, a photo of their "prototype" hardware was released, and it's just a stock embedded Ryzen dev board - not custom hardware at all. After 2 years, they had nothing done. It gets even better: They realized their original case design from 2017 was too costly and had to redesign it in Spring 2019: https://medium.com/@atarivcs/atari-vcs-structural-improvemen...
Even in 2019, all they had were renders of both their old and new case designs, and that blog post really goes to show how unprepared they were. Any moron with CAD experience could have told them their original design would have been a nightmare to manufacture/assemble.
As a drop-in replacement, it reads your existing Icecast config file, and writes logs in the same format as Icecast. It doesn't have every feature of Icecast, but all the major ones are implemented (relays, fallbacks, etc), and I've been using it to power my own audio CDN for the last year.
If anyone has any questions, I'd be happy to answer them!
See:
https://doc.qt.io/qt-5/qgraphicsview.html
https://doc.qt.io/qt-5/qgraphicsscene.html
https://doc.qt.io/qt-5/examples-graphicsview.html
Take a look at the types of applications they used for the examples. It'd be a good solution for something like a CAD layout widget, or maybe a maps widget. You use it together with Qt Widgets or Qt Quick, not instead of it.
I'd go with Qt Widgets by default, unless I was building an app that needed very strong branding, a unique UI, and had design help, then I'd go with Qt Quick. Curious to hear what others think.
(I've built a handful of desktop apps with Qt, but they're all tools for music or radio, so a flashy flat UI never made sense, so I've always stuck with Qt Widgets. No regrets.)
It's undermines their GCP business in a big way too - It makes you think that if they had to choose, they would throw their GCP customers under the bus to preserve their own other services. The value proposition of GCP is greatly diminished then in comparison to a dedicated cloud provider like DigitalOcean, who has no other competing interests. This changed the way I view some of these cloud providers.
eg. If Google had to prioritize ad network traffic over GCP, there's no question the ad network would get priority. But why not just go with a different provider who doesn't have to make that compromise?
Overall, YouTube measured a 10% drop in global views during the incident...
So what I'm hearing is that while Google Cloud Pub/Sub was down for hours, crippling my SaaS business, Google was prioritizing traffic to cat videos.
It's good to know Google considers GCP traffic neither important, nor urgent.
There's also some more common features in most IDEs like being able to jump between symbols that saves a lot of time day-to-day.
If I'm interviewing you and you say you don't like using an IDE or a debugger, that speaks to your work experience, your productivity, your self awareness about your productivity, and really puts an upper limit on the difficulty of the problems you've had to solve.
Yeah, that's what I was getting at. I feel like my chances of being collateral damage on an attack against someone else is way higher in the cloud.
Even today with GitHub and other SaaS platforms going down, we were all affected.
> "But technology providers in the United States could suffer blowback. As Dyn fell under recurring attacks on Friday, Mr. York, the chief strategist, said such assaults were the reason so many companies are pushing at least parts of their infrastructure to cloud computing networks, to decentralize their systems and make them harder to attack."
Pushing your infrastructure to cloud computing is not decentralization - it's centralization, and we're all doing it. Imagine if an attack like this was against AWS... we'd all be screwed.
On the other hand, the economy just doesn't incentivize open source communities to build the very best software for average users, compared to say, making a billion bucks with by building my new shiny walled garden social network. Anecdotal examples and lots of great FOSS project aside, cash is king and capitalism doesn't favour open source.
Still, if I can't make it work well on a reasonably small scale, why would I expect it to work any better when I scale it up?
Do you mind sharing which GlusterFS version you're on, which kernel, and roughly what your load profile is? (eg. lots of small files, read-heavy, write-heavy, etc.) Also, are you using Red Hat Gluster Storage or the open source version?
One has to wonder why the software even lets you run it with an unsafe number of nodes though... (Lots of distributed software is guilty of this...)
It was the whole shebang: Kernel panics, inconsistent views, data loss, very slow performance, split-brain problems all the time. Our set up IIRC was very simple: two bricks in a replicated volume. It worked so poorly that we had to take it out of production. Some of our experience can be explained by GlusterFS performing poorly under network partitions, but nothing could justify kernel panics. It blew my mind that Redhat acquired that company and product.
Edit: I hope there's been a big improvement to the reliability and performance of GlusterFS. Can anyone with more recent experience running it in production comment?