Live data from Hacker News

Could EU force hardware manufacturers to make working drivers for Linux?

old.reddit.com

181–190 of 369 posts

Re: Could EU force hardware manufacturers to make working drivers for Linux?

#181

Earlier quoted context omitted.

Sounds like it needs a special program and configuration, which is not needed on Apple devices. Also, KDE Connect needs both devices to be in the same network - which is not needed for Apple devices. My phone can be on 5G, and my Mac can be on wifi. Or they don't have to connected to a network at all.

> Sounds like it needs a special program and configuration, which is not needed on Apple devices How else would it work across different devices? Apple devices can not connect to e.g. Android devices without a 'special program and configuration' nor can they do so with Linux or Windows or whatever other devices. > Also, KDE Connect needs both devices to be in the same network - which is not needed for Apple devices K…

> How else would it work across different devices? Apple devices can not connect to e.g. Android devices

I was talking about Mac and iPhone having seamless integration - something I have not noticed of any other ecosystem. I have not been able to share clipboards with an android and a PC (Win and Linux) without installing an app, or doing some other hacky things. The integration, while possible, doesn't exist by default. It's not seamless. It doesn't _just work_.

> KDE Connect and other similar tools work fine over a VPN

I don't want to use a VPN? I want to use my regular home wifi or phone network, like a normal person.

Re: Could EU force hardware manufacturers to make working drivers for Linux?

#182

Earlier quoted context omitted.

I think you should look up the history of h.264 and see who is in the patent pool…

You should go even further and check the video playback experience on apple machines, when divx was all the rage and apple had just a sorrenson video 3. And yeah, full-screen playback was a qt pro feature, paid extra.

Or you can go even further back when Microsoft was caught stealing QT code because they couldn’t do video competently themselves and Apple could (circa 1995).

And every Mac geek knew how to work around it either via free third party software or just using AppleScript

https://osxdaily.com/2007/01/30/play-quicktime-movies-full-s...

Re: Could EU force hardware manufacturers to make working drivers for Linux?

#183

Earlier quoted context omitted.

And how many “multipoint” devices support an unlimited number of devices? I currently have 2 AppleTVs, a MacBook, iPad, an iPhone and an Apple Watch all paired to my AirPods . What’s the pairing process like? Mine is just - sign into iCloud and my AirPods show up.

I have JBL headphones currently paired with Samsung phone, tablet, Intel NUC running Ubuntu and MacBook Pro running macOS. No problem, no cloud login necessary.

That’s still less than the 6 devices I have..

Re: Could EU force hardware manufacturers to make working drivers for Linux?

#184

They don't necessarily have to: there's another, more comprehensive hammer they (or the US for that matter) could use: disallow vertical integration. Force hardware vendors to only sell hardware. If any software that can be changed remotely or by the user is off limits. Even firmware. Conversely, software vendors can only sell (or freely distribute) software. For vendors from abroad, don't go extra-territorial, just…

So your saying apple would have to stop making operating systems?

Or are you saying Qualcomm would be required to not provide drivers?

This is a super dumb take, like beyond stupid, and I get that it’s directed at apple.

Here’s the thing: since day 1 apple has been a hardware company, and what makes hardware good or bad is often the software that drives runs it. That goes for every product apple makes.

The idea that you can remove one half of that from the other is beyond stupid.

Re: Could EU force hardware manufacturers to make working drivers for Linux?

#185

They don't necessarily have to: there's another, more comprehensive hammer they (or the US for that matter) could use: disallow vertical integration. Force hardware vendors to only sell hardware. If any software that can be changed remotely or by the user is off limits. Even firmware. Conversely, software vendors can only sell (or freely distribute) software. For vendors from abroad, don't go extra-territorial, just…

> Force hardware vendors to only sell hardware. If any software that can be changed remotely or by the user is off limits. Even firmware. Conversely, software vendors can only sell (or freely distribute) software. So, I would go buy a smartphone at a shop, and then buy an OS to run on it at another shop? Or would it be allowed for a third party to integrate the two and sell me a working phone? Also, would “any softwa…

> So, I would go buy a smartphone at a shop, and then buy an OS to run on it at another shop?

Good point, by default you would. Perhaps allowing some third party to bundle the two could be a nice convenience, but then we must make absolutely sure that they never sell the bundle for less than the separate parts, that would be anti-competitive.

Also, I'm sick of paying for a Windows copy I never use. I'd very much like to see the OEM deals Microsoft make with laptop vendors just die.

> Also, would “any software that can be changed remotely or by the user is off limits” mean Intel/Samsung/… couldn’t sell CPUs with microcode installed, or even write microcode?

Depends whether that microcode can be changed by the user or remotely, or if doing so basically means returning the CPU to the factory. If it can conveniently be changed, that's software, and the actual interface to the CPU is not the final ISA, but how to encode that micro-code to make the final ISA. If however the microcode is etched or locked, then it's part of the hardware.

Another example would be an FPGA implementation of a RISC-V core: if the bitstream is locked into the NVCM it can no longer be modified, and thus counts as hardware. But if it's in the easily rewritable SPI flash, then it's software, and it can't be bundled with the FPGA itself.

While I'm not absolutely certain my border is the right one, I believe it's at least one that can be fairly easily delimited.

> Software company C could pay hardware company H to build hardware according to specs they give, with the specs under NDA, possibly even forbidding H to sell that hardware design to others than C.

Correct, some trade secrets need to be banned. Even further, I would void all ISA related patents and copyright. Specifically, cloning the functionality of any piece of hardware should be allowed, similar to how the IBM PC was cloned.

Note thought that splitting the activities is still worth it: when software is bundled with the hardware, we still need exploitable specs. Banning trade secrets doesn't force vendors to disclose them, and even if they do disclose them, nothing forces them to make especially readable beyond regulatory mandate, and nothing forces them to simplify their hardware interfaces. Exposing hardware interfaces to the competition however may provide very strong incentive to improve not only the hardware, but it's programming interfaces as well.

Re: Could EU force hardware manufacturers to make working drivers for Linux?

#186

This is why society is screwed. All these people don't understand the dangers of socialism. History is bound to repeat itself. The cost of the EU forcing everyone to adopt a standard is that next time a new manufacturer need to enter the market, it will have to cater to the need of the 1% (of which I am part, I'd love to have drivers for linux for everything). Who is going to benefit from this regulation? The existin…

I actually agree with your argument, but what does any of this have to do with who owns the means of production? Because that's everything socialism is about.

Re: Could EU force hardware manufacturers to make working drivers for Linux?

#187

Earlier quoted context omitted.

rather than "disallow vertical integration", start with "disallow lock-out". By all means, vertically integrate as much as you want but it should not be illegal for someone to take your hardware and use it for another purpose that you have no say in, or write and run software using your hardware without you having a say in that.

Yeah, someone on that Reddit thread said it right - force the companies to publish documentation for the interfaces. Let the hackers write the drivers without painful, slow and error-prone reverse engineering.

I wouldn't even go that far: by all means, don't publish your interfaces, but if someone reverse engineers them: legalize that. And don't offer tax cuts to companies that don't publish their schematics and interfaces.

Re: Could EU force hardware manufacturers to make working drivers for Linux?

#188
post #110

Earlier quoted context omitted.

What is KDE Connect? Which incidentally runs equally well on other desktops and even windows. https://userbase.kde.org/KDEConnect Also gsconnect can provide integration with gnome. https://extensions.gnome.org/extension/1319/gsconnect/ KDE Connect is a project that enables all your devices to communicate with each other. Here are a few things KDE Connect can do: Receive your phone notifications on your desktop comput…

KDE Connect requires both devices to be connected to the same network, which means you have to connect your devices to the same VPN if you're on a wifi network with client isolation (most public wifi). If you're away from wifi, you'll have to configure one of the devices to be an access point and join everything else to that device. Apple's clipboard/handoff/continuity automatically works as long as the devices are w…

For what it's worth, Connect does have a Bluetooth backend that supposedly works: https://invent.kde.org/network/kdeconnect-kde/-/tree/master/...

It doesn't seem to be enabled by default though. I'm not totally familiar with the situation, but I'd assume it's a problem with multi-device handling and switching to the best backend. For most people/situations, the Wifi Direct option will be faster and lower-latency.

Re: Could EU force hardware manufacturers to make working drivers for Linux?

#189

Earlier quoted context omitted.

I have JBL headphones currently paired with Samsung phone, tablet, Intel NUC running Ubuntu and MacBook Pro running macOS. No problem, no cloud login necessary.

That’s still less than the 6 devices I have..

Next you're going to ask how high into the air I can piss?

Re: Could EU force hardware manufacturers to make working drivers for Linux?

#190
post #165

They don't necessarily have to: there's another, more comprehensive hammer they (or the US for that matter) could use: disallow vertical integration. Force hardware vendors to only sell hardware. If any software that can be changed remotely or by the user is off limits. Even firmware. Conversely, software vendors can only sell (or freely distribute) software. For vendors from abroad, don't go extra-territorial, just…

This is completely impossible with any hardware made in the last 20 years or so. The problem is that you cannot make a hard distinction between hardware and software. An Intel CPU simply isn't going to run without microcode, and having to get rid of microcode would easily set back chip design by a decade. Even something as trivial as a USB cable isn't pure hardware anymore. It has a programmable eMarker in order to a…

> The problem is that you cannot make a hard distinction between hardware and software. An Intel CPU simply isn't going to run without microcode, and having to get rid of microcode would easily set back chip design by a decade.

Yes you can make the distinction, and no it doesn't require getting rid of the microcode: https://news.ycombinator.com/item?id=37731829

Simply put, if the microcode can be updated by the user or remotely by Intel, then it count as "software", and Intel should stop shipping it. But if those update are either impossible or require a factory recall, then it's "hardware", and Intel can happily continue to ship it.

The same logic applies to the USB cable, and even FPGA: if the bitstream is locked into the NVCM, that's hardware. If it's merely written in the rewritable SPI flash, that's software. It's not a property of the bitstream itself, it's a property of how it is stored.

Obviously the cost of micro-code bugs will sharply increase. That's kind of a feature though: now hardware vendors must be really careful.

Post reply on HN