I think there are two main reasons to download from yt. The first one is that a lot of music is only available there. Services or torrents are not as vast as one would like when you are looking for something specific.
The second reason is that services that provide offline usage are cumbersome to use in certain escenarios; eg: old car stereo
I think Uber/lyft thought that self driving cars would arrive earlier than these regulations. Now they have to face a great difficulty to adapt to the new environment
It’s a little off topic, but today you can get a self driving ride in Las Vegas through the Lyft app. Two safety drivers sit up front though so it’s not driverless.
Surfraw (Shell Users Revolutionary Front Rage Against the Web) is a free public domain POSIX-compliant (i.e. meant for Linux, FreeBSD etc.) command-line shell program for interfacing with a number of web-based search engines. It was created in July 2000 by Julian Assange
It's a neat technology but still quite infant. I've heard that it currently takes longer to implement a non-trivial UI due to the compiler errors, documentation gaps, and bugs with the framework. Patience is required.
The latest stuff in beta since WWDC makes a world of difference. It’s a joy to play with, and I haven’t encountered any of the impenetrable compiler errors that the last version had.
I'm always very careful whenever apple release new technologies for devs. They promote it heavily but actually nobody uses it inside, and it's up to the community to go through all the bugs.
> They promote it heavily but actually nobody uses it inside, and it's up to the community to go through all the bugs.
Large chunks of macOS 11 and iOS 14 are built with SwiftUI, and it's the only way you can build the newer style of widgets on both platforms. They're actually pretty aggressively dogfooding it.
They were slow to pick up Swift internally because they needed ABI stability, but no such barriers exist for internal adoption of SwiftUI.
I'm using it to port an auv3 plugin to a standalone app. The overall experience is amazing when compared to the constraint based method proposed in previous xcode versions. There are parts missing, but it's fairly easy to wrap uikit components and use them in swiftui
It's really sad that people (managers) still thinks of code this way. Luckily this has never happened to me, but if it did I think it would be a great sign to change jobs.
I don't agree at all. The reasons in the article all seem like "envs are bad because if you make a mistake you can expose them". This is not exclusive to envs, it applies to all secrets, independent of the medium used to make it available to the process using it.
In my experience, if you prevent using envs for secrets (as docker swarm does) all you get is a disgruntled programmer reading the contents of a secret file to an env in the entrypoint.
I think what the author means is environment variables are particularly vulnerable to being logged by accident, because:
1. They're stored right next to variables like PATH, JAVA_HOME, LC_ALL and PYTHONPATH which people might plausibly decide to log out every time
2. They'll get printed any time someone writes a shell script with set -x then uses the environment variable.
3. They'll probably end up in your developers' ~/.profile or ~/.bashrc, meaning any program logging the environment will log it, not just your program
4. Because they'll be in ~/.profile or similar, the secret will be in a file on disk anyway and a secret that's in one place is always better than a secret that's in two places.
With that said, a lot of CI servers that support "secure variables" offer those as environment variables and nothing else. So I can understand why people might end up stuck with environment variables despite their downsides.
This all seems like a lot of work for a problem that seems largely theoretical. How often do Fargate or Lambda function VMs get broken into in the first place? I could see this maybe being a concern if you're running big, long-running VM instances with lots of collocated services (as well as utilities for process management, ssh support, log exfiltration, package management, etc and all of the extra drudgery/attack-surface you have to manage yourself when you opt out of serverless).
Also, application secrets for development environments probably shouldn't be super sensitive in the first place, right? For example, for a third party API key for a service like Auth0, we would have a dev tenant within Auth0 so even if a developer's environment is compromised, it can't jeopardize production.
It's really the latter half of your fourth point. Many programs log envvars for either debugging or intrusion detection purposes just like they run command invocations. In a multiuser environment this can be problematic, especially in a business with multiple security areas. E.g. you don't want IT (that can read the logs) getting access to production resources in a hard to track way (by reusing a production key instead of their more closely monitored access system).
I tend to stick to files, it's just more convenient and reusable. But if you're on a single user system don't worry about passing things via the command line or via envvars.
>1. They're stored right next to variables like PATH, JAVA_HOME, LC_ALL and PYTHONPATH which people might plausibly decide to log out every time
No, they aren't. You just create a .env file in your project root and run "source .env" before you run your application.
Unlike Windows there are no global environment variables on Linux. All of them are hierarchical and only exist within the process they were created and its children.
> 1. They're stored right next to variables like PATH,
So what? If the problem is that people might accidentally log secrets then the problem is not env variables.
> 2. They'll get printed any time someone writes a shell script
The set -x flag is a debugging flag to print out traces of a shell script being executed. This flag is disabled by default. Why is this far-fetched example being used to justify not using env variables?
> 3. They'll probably end up in your developers' ~/.profile or ~/.bashrc,
No, they don't. With containers you may launch devel env variables some way or another (env files, setting up the IDE, setting env variables manually) but at most they are a part of a testing config. The env variables used in production are handled by the deployment.
Even if you're able to sniff a env variable used in development, that has nothing to do with the production service.
> 4. Because they'll be in ~/.profile or similar, the secret will be in a file on disk anyway
This complaint makes no sense at all. No container orchestration system stores env variables in ~/.profile although their containers use env variables For secrets extensively. The container orchestration service provides secret-management services, including setting up the env your containers are launched, and all you need to care about is that your container needs to accept certain env variables that you will use on your app.
Even if you deploy services on bare metal, you should still use env variables for config and secrets, but you need to be able to manage secrets and rotate keys with a non-pet method.
> So I can understand why people might end up stuck with environment variables despite their downsides.
I'm sorry but you failed to both present any downside of using secrets and point out any scenario from the real world. I mean, anyone who ever read any intro tutorial on how to deploy a system is well-aware that you should not store passwords and keys and secrets in plain-text files. That has nothing to do with using env variables at all. In fact, all your examples are entirely oblivious to the standard workflow of deploying a service, moreso if it involves a container orchestration system.
So if the examples don't have any relation with basic practices and real-world workflows, why should anyone avoid using a best-practice?
There are actually key/value stores that solve this securely, such as Hashicorp Vault.
The issue isn’t that it can’t be done but more that most people either don’t already know it can be done or don’t want to invest in the infrastructure to do it.
Regarding the latter point, for self hosted solutions I can sympathise a little and it’s really a question of risk analysis. But most cloud computing services do offer their own secrets management service.
(not affiliated with Hashicorp and other services exist).
The problem with Hashicorp Vault (and their peers): Your application still need a secret to access values made available to your application's role.
The values might not be in the immediate container space (well, aside from being in program memory), but they're only one (likely well documented internally to the container) hop away.
I've constantly tried to figure out the answer to this. Is there literally any solution to this that doesn't involve the access key for the secrets vault being supplied by human input / secure hardware? But even in the case of secure hardware, if the hardware trusts the requesting application and that application becomes compromised, doesn't that defeat the purpose? Where is trust anchored?
Sure, and they are great. But in some cases, it's inevitable to read some secrets from the secret management service to envs. This is what docker swarm doesn't allow with the 'docker secret' command
The DSP module in JUCE isn't production quality, and the audio I/O integration in RtAudio is good enough for even professional use cases.
JUCE is really painful to use if you want to integrate it into anything modern. It's old, it's slow, and you really can't make it better. I really can't express how much distaste I have for JUCE after shipping multiple products built on it - it solves _one_ hard problem (wrapping AU, AAX, and VST3), other than that it is dog slow and can't be improved because the core devs don't accept outside contribution for no reason except their own hubris.
Any cross platform UI in C++ that isn't JUCE or Qt is highly welcome. Especially one that allows me to pull in external dependencies and use modern build systems, test frameworks, CI/CD, and other tooling.
I have been playing with Dear Imgui lately, and while its super easy to get up and running, I realized it doesn't have support for zoom (cmd +) and accessibility (unless I missed something).
It seems like those features are out of scope for the library - which is fair, one has to draw the line somewhere, and there are enough success stories with the project that it may not matter to a lot of the people. The author has mentioned in various places it's mostly for internal tools or game dev, which makes sense.
I am glad more toolkits are coming up (both for C/++ and Go, the languages I am interested in writing desktop apps with), but I am a bit surprised Qt seems by _far_ most mature compared to a lot of newer tools, not counting wxWidgets or glade/gtk3.
Very few C++ UI frameworks deal with accessibility or platform UX standards like zoom (ctrl +). You have to use platform/native APIs directly, or frameworks that seek to model them (which usually are not native).
It's not unsurprising to me that Qt is the most mature. It's the oldest, most widely used, and probably the most well financed...
I suggest looking at wxWidgets. Fully cross platform, no commercial/paid version, all open source, without any of the org issues facing QT, and it's... a classic GUI.
I'm interested in seeing if Elements can integrate. WxWidgets has the typical amount of code (more than a little, but not much more) to create one's GUI. There's significantly more than just a GUI, BTW.
I also tried Dear Imgui, but had to back out due to the constant rendering requirement of Imgui, because my applications are already hi-compute and a persistent GUI is required when you're already pushing the CPU without any GUI.
Qt is lovely but the company that controls it is in a bad place financially and it's not clear what will become of Qt if they go under. There's also the issue where if you get a commercial Qt license it's much more difficult to contribute to Qt under GPL or LGPL. And of course the license is tremendously expensive unless you're making serious money with the application, so prohibitive to smaller companies. I love Qt but I would never feel comfortable using it in a commercial project. There was also this bullshit earlier this year where they tried to pressure KDE into worse terms https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...
> Qt is lovely but the company that controls it is in a bad place financially and it's not clear what will become of Qt if they go under.
this part has always been clear:
"Should The Qt Company discontinue the development of the Qt Free Edition under the required licenses, then the Foundation has the right to release Qt under a BSD-style license or under other open source licenses. The agreements stay valid in case of a buy-out, a merger or bankruptcy."
Yep, but a hostile entity that owns Qt can do a lot of damage to Qt by publishing on the last permitted day, and denying community contributions and destroying community governance. I can definitely imagine a hostile corporation like Oracle doing so (and they have form).
Qt is still available as GPL. Even if the Qt company goes under today and nobody picks up development, it's stil a great package for many years to come.
I agree behavior lately is not great, and a Qt company in trouble won't be good, but I think the community will pick up quite a bit if it comes to that.
I also think many misunderstand or misrepresent the implications of a GPL only Qt (for closed source applications). It's a matter of linking correctly: https://news.ycombinator.com/item?id=23321448
Right, of course it is, but if the Qt company goes under the highest risk is that its assets get purchased by a hostile entity, which releases everything with a year's delay and doesn't allow community governance/contributions. Imagine Qt owned by Oracle and you'll understand my concern. Of course if that happens KDE and the other current Qt users will likely fork it, but someone like Oracle can do a shitton of damage to the community in the process by threatening litigation.
The issue with the commercial licensing is that if you are a commercial licensee you are contractually prevented from contributing to Qt in some ways. See https://www.qt.io/terms-conditions/ and search for "Prohibited combination". If you are able to comply with the GPL or LGPL components without becoming a licensee, this is better in every way (you get to contribute, you have much more legal safety if the company gets acquired by a hostile entity, you don't have to worry about what happens when your license expires, and of course you save money). So those license terms are actively preventing the Qt company from getting revenue, because you get a worse deal in most ways if you pay them than if you don't. This is why I'm uncomfortable with Qt in non-GPL/LGPL commercial projects. You get trapped and you can't relicense your project to GPL afterwards even if you want to.
I really dont get why people still throw FUD with this argument. It's been what, 25 years already since this argument lead to the KDE Free Qt agreement?
At this point the biggest concern for the Trolls (or whoever owns Qt nowadays now) should be that the FUD against GPL is starting to slowly evaporate, so even big companies are starting to use GPLd Qt rather than pay licenses. By the time they go Oracle there will not be much they can do.
I did briefly. The CMake integration is... quite strange. It kind of has to be because of how strange the compilation model is for a JUCE project, where all your includes depend on having the same set of preprocessor definitions.
I switched to Juce 6 preview branch last week. It's not without problems but getting rid of the Projucer is amazing. Now you can have a clean CMake setup and you are not stuck with Xcode on the mac.
JUCE is a reasonable comparison, as Elements specifies it wants to be a UI for plug-ins like VST & AU, and JUCE is dominant in the audio plug-in space.
