111–120 of 123 posts
Earlier quoted context omitted.
RMA for miserable sound ?
Bluetooth is absolute garbage for serious audio. Wired will always sound better, and a DAC + Amp driving the cans will always sound the best. Sennheiser does make BT headphones with a dedicated tower that helps a bit, but nothing can replace a hard line.
Earlier quoted context omitted.
I would like to inform you that it does in fact work really rather well. I write this on a laptop running Debian Linux which I use for work. It's great. I also use a machine running Debian Linux for my personal computing needs, but prefer to separate those concerns a bit. I can confirm the community's support is excellent though.
It doesn't work at all, for the thousands of pieces of hardware that simply don't work on Linux, or work poorly. Further, it doesn't work at all from an economics standpoint. There is zero incentive driving the community to support every iteration of every type of hardware other than personal need, and if you're suggesting that anyone who needs something has to go out and build a driver themselves, please let me know…
So many hardware companies fell into the trap of making steaming piles like ATI's CCC[0], Creative's SoundBlaster Control Panel[1], ASUS's Control erm.. thing[2]. And it's not just gaming peripherals, buy a computer from HP and see how many HP-specific utilities clog up the system tray. Same goes for most of the other big players.
I just want the OS and the drivers thanks.
[0] https://www.screenshots-archive.com/ati-catalyst-control-cen...
[1] https://i.imgur.com/POZVXQj.jpg
[2] https://img.purch.com/o/aHR0cHM6Ly93d3cubGFwdG9wbWFnLmNvbS9p...
Earlier quoted context omitted.
I would like to inform you that it does in fact work really rather well. I write this on a laptop running Debian Linux which I use for work. It's great. I also use a machine running Debian Linux for my personal computing needs, but prefer to separate those concerns a bit. I can confirm the community's support is excellent though.
It doesn't work at all, for the thousands of pieces of hardware that simply don't work on Linux, or work poorly. Further, it doesn't work at all from an economics standpoint. There is zero incentive driving the community to support every iteration of every type of hardware other than personal need, and if you're suggesting that anyone who needs something has to go out and build a driver themselves, please let me know…
And for those people there are companies like Canonical, who derive their product from Debian. There is also Redhat, SUSE, etc. Lots of commercial options grow up around these vibrant communities to fill the gaps that they sometimes leave. This is an unmitigatedly good thing.
Earlier quoted context omitted.
In this case we started doing hybrid cloud, we were unable to address a ton of sites since they were on a made up internal only tld. Plus every thing we could address served up certs we couldn’t trust since we were utilizing services that didn’t allow us to modify the trusted root cert store. We saved probably $100 and 2 hours by rolling our own solutions instead of doing things the standard way. It took weeks to cle…
Well, yeah, using a made up domain is obviously a bad idea ... but what does that have to do with root CAs? And how does trusting your own root CA lead to not trusting the certs presented by other parties? I don't really understand what kind of scenario you are describing there. And no, I don't see anything "standard" about not running your own CA, it is perfectly standard as far as I am concerned, and a really good…
> the software was also installing a root certificate into the Trusted Root CA Certificate store. This kind of stuff shouldn't even be legal.
I have to STRONGLY disagree. It's a slippery slope towards a world in which the computers we use are completely locked down and we have no control over what they trust, being dictated by the corporations and their interests. The freedom to modify your roots of trust is extremely important and situations like this should not scare us into depriving ourselves out of that. I say this as someone who runs an adblocking/fi…
Earlier quoted context omitted.
Well, yeah, using a made up domain is obviously a bad idea ... but what does that have to do with root CAs? And how does trusting your own root CA lead to not trusting the certs presented by other parties? I don't really understand what kind of scenario you are describing there. And no, I don't see anything "standard" about not running your own CA, it is perfectly standard as far as I am concerned, and a really good…
Obviously if all your services are hosted in house and you will never need to expose internal services externally go for it. But as soon as your organization grows, splits, merges or starts utilizing other services that don’t give you access to the trust store you are boned. It screwed us, and was a giant pain to fix.
For one, there is no problem hosting your own services elsewhere and having them use your own certificates. But more importantly: Why should your own CA prevent you from obtaining certificates from an external CA for external services? I mean, it just doesn't, that's how I run stuff: Purely internal stuff runs on internal CA, stuff that needs to face the public somehow runs on globally recognized CAs. And it's mostly trivial to switch services from one to the other - or to just run two endpoints, one using the internal CA, one using an external CA.
It seems to me like your problem wasn't your own root CA, your problem was that your services were incompatible with external CAs for some reason, among them probably your private DNS root? But that isn't a reason why you should put your internal services at risk from mismanaged public CAs, that's simply a reason why you should use a global domain and support provisioning of certificates from external CAs.
Earlier quoted context omitted.
Of course it will show the cert with the matching name, practically all MITMs will generate the correct certificates so that browsers don't complain. You need to look at the CA it's signed with, and compare to the one you get when you access the site from somewhere else. Also, It's also extremely common for companies to install root certificates on work computers that employees use to check their personal email. Why…
>Because you do not own those computers, and they should not be used for non-work-related activity. The company policy will explicitly mention this, something like "all communications on company property are subjected to monitoring at all times." Just as a thought experiment, lets say I set up a "free computer booth" on a street, but made people tick a box when they started that expressed the same conditions. Would I…
Earlier quoted context omitted.
Why? The user chose to run the installer and opted to give it control to modify their computer. What part of that process should be illegal?
They give permission to modify their computer/device, but obviously there's an implicit trust that it isn't going to do something horrifically bad. Trusting a builder to come in to your home and change things- you'd be pretty angry if they took down a supporting wall to put up a new light fitting (and you'd probably have some legal comeback).
Earlier quoted context omitted.
Obviously if all your services are hosted in house and you will never need to expose internal services externally go for it. But as soon as your organization grows, splits, merges or starts utilizing other services that don’t give you access to the trust store you are boned. It screwed us, and was a giant pain to fix.
Why would all your services have to be hosted in house and why would it prevent you from "exposing internal services" (I mean, apart from the fact that they kindof aren't internal services anymore from that point on)? For one, there is no problem hosting your own services elsewhere and having them use your own certificates. But more importantly: Why should your own CA prevent you from obtaining certificates from an e…
