missjellyfish

I'd further argue that it would be important if your program does anything useful without the GPL parts; if so, you can probably argue that it is not a derivative work. If you however only build an extension to some GPL'ed software that fundamentally needs the GPL'ed code to properly function and cannot (easily) be used by any other software, then you probably will create a derivative work.

Yes, all of the above is on the condition that some distribution happened (and you can prove that).

However, distribution also happens in places you might not expect. As a business, I'd stray far away from such constructs even if I only use this construct internally.

However, this is purely based on the wording of the GPL. For example, the EUPL explicitly covers the creation of derivative works - and I'd argue that the proposed circumvention would create a derivative work.

The end result will most probably violate the GPL. However, this is only realized by each user; you could probably argue that you never test your software and only look at API documentation.

And then it becomes a problem of proving your users violating the GPL. So you'd have to go after each one of them, which will be incredibly difficult, and proving damages would be even more difficult.

It's an asshole way of exploiting "Wo kein Kläger, da kein Richter" (where's no plaintiff, there's no judge) since actually proving that the developers violated the GPL will be difficult, unless they have a CI system that readily documents this.

I'm not entirely sure if this is even possible the way copyright in the EU works today. Be that as it may, at least from my perspective what really prohibits me from actually enforcing GPL on my software is funding. I rarely go beyond sending a stern letter, because anything more would be financial suicide in most cases; I might win but it is incredibly hard to prove damages. Punitive damages don't really exist in the EU (or, to be more precise, in the roman-german law system), at least not to the exterme seen in common law systems.

At least in my case, I'd fight tooth and nail for my software, if I don't have to bear the financial risk.

I was simplyfying. What I described is unified in the European Union; however, the outlined distinction is common across the roman-germanic law system whereas the US copyright interpretation is rooted in common law. In Europe, the only countries using common law are UK and Ireland. And while Ireland has mostly unified their copyright law with the rest of the european union, you still see some roots in common law. For example, it is possible that an irish company (a legal person) can become an author of a work, which is impossible under e.g. german law.

And yes: in a common law system, copyright governs literally "the right to copy", which is transferable. In other law systems (which is the distinction I made) the law governs the property rights of the author's expression, which is non-transferrable, you can only license the rights you have.

Copyright in Europe fundamentally does not work like Copyright in US. More precisely, the law does not govern the monetary gains possible from copying but rather the author's artistical expression in the work. Which is kind of moot regarding source code, but, it makes for an important decision: author's rights are created automatically and you cannot transfer them under any circumstances whatsoever.

Per default, the law states that the author retains all rights. They can license it, e.g. to their employer, exclusively; The employer can then sublicense that. However what licenses are possible is exhaustively defined in the law; on an abstract basis at least (e.g. using, creating derivative works, ...). It has been not exactly clear if conditions evoked on a license still have their roots in these licensable acts, or if they are based on contract law - where literally anything goes as long as it's not against the law or immoral.

Both can be enforced. However, I'd argue that it is good that it was decided that this is a copyright law matter, because this gives authors _much_ more protection than contract law, where all circumstances need to be evaluated for each single case and rulings might as well contradict each other.

Not a lawyer yet, though.

Trademark law always hinges on the question if a reasonable consumer with reasonable knowledge could be expected to distinguish those trademarks or not.

HDMIY would most probably not fly, HDIY would probably.

not yet a lawyer, though.

edit: I'm also fairly certain that the HDMI forum would fight HDIY tooth and nail, so whoever goes public with that absolutely needs deep pockets.

Someone needs to reverse engineer and publish the spec ASAP. This is ridicolous.

Telephone Line Voltage is anywhere between 48 to 90V DC, depending on where in the world you are and which standards apply.

Give MediaMonkey a shot. If you play local files, it’s the best player I ever had the pleasure to use.

Wow, thank you. Of all things I considered happening when posting my snarky winamp remark this was not something I expected. Will check that out.

I like how they fail to mention that the Apple Music App on Windows is hot garbage riddled with bugs. A few weeks ago they broke reordering of upcoming songs, the "play next" feature and I don't know what else.

I have submitted bug reports with exact steps, reproducible on at least two accounts on five different conmputers. Haven't heared back, doubt I'll ever will.

Anyone can recommend a streaming service that isn't Apple Music, Spotify or YouTube Music? Bonus points if I can just add a plugin to my old trusty winamp to use it.

Exactly the reason why I am rocking a Broadcast Headset (Beyerdynamic DT-797PV, to be specific) for work calls. It has XLR for the microphone and 1/4" for the headphones. All goes into a cheap Behringer UMC22. Never had any problems with Teams, Zoom, ... you name it, my colleagues using bluetooth have constant issues, be it with connectivity, audio quality or both.

Also since I wear glasses all day everyday I will never use any headphones that don't have velours earpads. So much more comfortable than faux leather.

If so, I'd much rather have miniDP. Better connector, better standard, it talks HDMI anyway if you want to, and you will need an adapter anyway.

That would probably be fine by me if and only if:

a) the source code of the secure enclave is 100% open source b) I can compile my own version of it c) I can run my own version of it d) I face no reprecussions (i.e. services not working, DRM not working, ...) if I choose to do so.

This is all fine and dandy for key storage purposes; you actually want all of these to guarantee that your keys are safe. But modern enclaves are primarily used for DRM, and this just doesn't work if I can just patch a way into my enclave to get the key if I really want to.

So, I'd much rather have a system with no enclave which I can attach a HSM to than a secure "trust me bro" enclave.

DRM was the original sin of computing, and nobody can convince me otherwise.

Write first, layout second.

Layouting is an entirely different job than writing. For long and very long textual content, I have yet to find automated results that give me control and look professional [0].

If you want to stay FOSS, learn Scribus. Becoming decent at typography and layouting is a bit of a journey, but I found it to be not too bad. If spending some money is okay, I'd go for Affinity Publisher.

None of those tools can do ePub. ePub is a format I've grown to hate; my pipeline currently consists of custom python -> pandoc -> custom python -> manual fixing.

For writing, don't worry too much. Use a program that you're familiar with and know how to use. If you don't write fiction with highly complex custom worldbuilding, a normal word processor is probably fine. I personally write urban fantasy novels, and I use a combination of Word and OneNote to manage everything as long as I am in the writing phase. It's more important to be easily able to change the layout than to have it finalized. For example, I like proof reading on Normseiten (A4, 30 Lines per page, less than 60 characters per line, monospaced font - I use Comic Mono) which is distinct from my usual writing format (Adobe Garamond, 12cm by 19cm pages with uniform 1.5cm borders).

What are my options in terms of self-publishing?

Depends on the subject matter. If you're writing is any good, might as well try and score a distribution deal (at which point most of the layouting things will be out of your hands anyway).

All the best for your book project.

[0]: LaTeX sure looks nice, but gives me no control at all.

I still have my local NAS and will in fact be upgrading it sometime this or next year. I don't trust cloud computing with my data, even tough I'd rather forgo the complexity and electricity cost.

But that's my price of freedom.

Proposing a layout based on US-ANSI is the definition of madness. We can discuss what's on the keys, but my ISO layout stays.

Author here - there are two main problems with directly constructing frames on an esp: first, espressif only very recently opened up the wifi stack to a point where raw frame construction is supported and even this has some limitations on which frame types are supported. There is an, erhm, liberated API on older SDKs that supports some more frametypes, but both cannot be used to construct encrypted frames (which is kind of reasonable, I assume that encryption is done purely in hardware).

Second, the more practical limitation comes from the fuzzing objective: esps are slowwwww, and the testcase throughput is abysmal; especially if you factor in that the firmware is essentially a black box and the usual coverage-guidance used in modern fuzzing simply does not work on a device that constrained.

So yeah - constructing frames on the esp would be the smart thing to do, figuring out how to do this efficiently (and fully automated) is however not trivial at all. FWIW, hooking the board up to a computer via serial is also not enough, the fuzzer needs some way to hard reset devices (that is, pull the reset pin to ground or powercycle or both). We use some extra microcontrollers we had lying around for that, however we needed to make some custom PCBs to make that work reliable.

Edit: also, to clarify, the esp8266 is even more limited than the esp32. There is no officially supported way to construct raw frames on the 8266, and in/out connections other than wifi are limited to fairly low speed UART (no JTAG, etc..).

I do. Hence why my discord persona is essentially made up and used as a marketing tool for my artsy hobbies, same way as my instagram profile is carefully curated to be something I'm not.

On the other side, humans have been fine using natural language to delegate commands to each other.

And that's why all of aviation has moved to a tight phraseology, such that delegated commands are universally understood and their meaning is set in stone.

Natural language has cost many lives.

If it doesn't solve the problem (which it doesn't! Many glaciers are already gone, there's nothing we can do about it), it's not even a bad way, it is just no way to _solve_ the problem.

It's the best way _to not make it worse_. Carbon Capture doesn't save us from making it worse. It can however undo parts of the damage.

The solution isn't to just freeze the status quo, that's what I'm saying.

The best way to fix the CO2 problem is stop producing it, not to try to clean it up.

I'd have to disagree. Stopping the production is important, but that doesn't solve the problem, it just doesn't make it worse. A true fix would always include removing some CO2 from the atmosphere, however that may be done.

They're already trialing overhead wires on some highways for electric trucks.

Yes, and it's a bad idea. The friction between tarmac and rubber is orders of magnitude worse than steel on steel. Electrification alone doesn't solve the problem.

I have a few more revolutionary ideas for this.

First off, we need to get this environmentally clean. Obviously, this must all be electric. For last mile, battery electric is the obvious choice; however I think for main routes and highways some kind of wire system would be ideal. This could also charge the battery needed for the last mile or at truck stops and stuff.

Next, we need to make sure that these self-driving units (SDUs) are always centered under that wire. Software would be an easy choice, but with the power delivery arm attached any failure would result in infrastructure destruction, so I'd propose a system of steel guards that force the wheels such that they can't escape the predefined envelope.

Come to think about it, rubber-on-concrete is ridiculously bad when it comes to efficiency, so maybe the SDUs should have two sets of wheels, one for last mile and steel wheels for the much more favourable friction coefficient. Then we should couple these units together, because the combined traction force equalizes loads across the whole chain and makes for better acceleration of the linked units resulting in less traffic.

Finally, we should equip these SDUs with a radio like GSM or something such that they can communicate with each other and drive in breaking distance, so we can increase the overall speed limit.

Gosh, I wonder why nobody has thought of this before.

Buses won't work in a lot of the U.S. because of last-mile issues, in the way the suburbs were designed.

Roads won't work in a lot of the U.S. because of tax revenue issues, in the way the suburbs were designed.

On a more serious note: there is no point in building unsustainable transit for neighborhoods that can't even support their own infrastructure. Suburbia will always be car-dependent for exactly this last-mile issue, but the fix is to shorten the last mile such that a bus actually makes sense. Because even to run an automated car you need a road that needs to be maintained and paid for from time to time.

edit: also, busses don't necessarily mean "20m long with capacity of 100 people". Here in Europe we have small bus lines operating with busses of a capacity of 20 people. In fact, Vienna already has the exact thing you propose: https://www.wienerlinien.at/eportal3/ep/contentView.do/pageT...

In Operation since June 2019. Results are mixed.

Small boring self-driving cars, possibly collectively owned instead of big expensive individually owned cars often used as a proof of social status.

So, a bus?

Because at the time the equipment was bought, it met every applicable federal standard. This would be unfair to the owners who had no way of knowing about the issue.

At least in Europe, there is precedent that modern use of frequency assignments make older equipment illegal to operate. 4G and 5G have heavily eaten into the frequencies used on stage for event equipment - microphones, IEM, that sort of thing. Many, many pieces can‘t be legally operated anymore, and it‘ll probably be the same in a few years time with the current-gen devices (although I hope I can swap crystals if needed and keep using my stuff).

Radio bandwidth is a scarce resource. If the radio altimeter is transmitting well outside of its boundaries and it creates problems (for any of the parties requirements), it’s the radio altimeters that need fixing. Even if it is expensive to do so.

What many people in this thread get wrong is that the problem is not and never has been posts, photos or messages shared with the public or a person that can reasonably be expected to be in the US. This data is mad explicitly public, and by posting, the user grants consent to distribute - worldwide. The problem is, however, with tracking data facebook runs it’s advertisements on. This data is compiled from a number of things, but must be orderly protected. That is - in my opinion - only possible in a federated service model. Anything that is explicitly shared and needs to be delivered in the US (or anywhere, for that matter) still will be. The GDPR and the concerns over the SCC only concern the ad path. Federating facebook will likely hurt their ad business, and, to make it worse, they still need to ensure the US has no jurisdiction (even if they would like to have it). This seems only possible by making the federated company 100% independent, which brings its own problems.

The reality is that Facebook (and meta, for that matter) very well could do that. But they probably won’t, because it would hurt their bottom line.

You can use Radeon cards, some are supported and when they are they run decently. But anything other than a GTX760 is not going to work, and I can assure you that the drivers Apple ships for this card are absymal.