Hacker Newsnew | past | comments | ask | show | jobs | submit | LexiMax's commentslogin

> This will sound crazy but this is why I still use 4chan. Everyone is anonymous, there is no voting, and the only moderation is to remove illegal things or flagrant rule breaking.

What you see is a mirage.

The problem with 4chan is that the loudest voices are the ones that have no lives, and can flood the board with their bullshit. You could be having a conversation with someone in one thread, meanwhile they're busy posting about the same damn thing in 3-4 other threads at the same time.

And that's assuming the person on the other end is real. These days, there are bot armies of paid shills or AI to worry about, flooding the zone with their narrative to the point where your voice gets drowned out.

You cannot have a decent social space without some form of active moderation and some protection against sockpuppeting. Not every place with both of those gets it right, but without both you're guaranteed to fail, and 4chan has neither.


Most of the social spaces that I frequent don't have the amount of political topics posted as HN.

Would you like to know the difference between those spaces and here? It's that in those spaces, regardless of if the members are left right or center, the community is on the same page in terms of authoritarians, and authoritarian apologia will get you tossed.

Therefore, there isn't the same sort of desire - or need - to point out the obvious and show the uncomfortable realities to the crowd.

Refusing to take a stand on this sort of thing and leaving it for the community to sort out will only make things worse. It's functionally no different than the kind of combative environment you get on major social media networks; the only difference is the amount of tone policing caused by the user-facing moderation tools.


What is preventing Microsoft from pulling an Oracle and suing Valve, CodeWeavers, or individual Wine maintainers for re-implementing Win32?

This question has been nagging at me for a while. Regardless of how much validity there is to the lawsuit, I imagine that going to trial would be supremely risky, because if you happen across anybody working on Wine that saw something they weren't supposed to, you could sink the whole project.

I cannot imagine Microsoft sitting by and quietly letting their Windows monopoly vanish between their fingers. Selling Windows may not be their primary focus these days, but why give up an advantage like that?


First, they probably wouldn't win. Oracle lost Google v Oracle. Wine is pretty serious about clean-room principles -- they won't accept a patch from anyone who's ever so much as looked at Microsoft-owned source code.[1] Valve has the means and motive to fight a lawsuit to the bitter end.

Second, it would be a PR disaster. "Microsoft sues to kill the Steam Deck" is an awful look for the company. Their strategy in recent years has been to say "actually we like Linux now" and play friendly to try to win developers; this would run completely counter to that. There may not be much of an immediate consequence to this, but in the long run I think we'd see developers try to reduce their reliance on Microsoft/Windows.

Third, I don't think it would actually stop the tide. Wine and Proton are a big piece of the movement away from Windows, but they're not the only piece. The legal process would take many years to play out; during that time, we'd likely see tons of movement on making it easier for developers to create native Linux builds, and perhaps even new projects that try to find other ways to do Wine-like things without actually reimplementing Win32. Losing Wine would be a huge blow, but I don't think it'd be the end of the story.

[1]: https://gitlab.winehq.org/wine/wine/-/wikis/Submitting-Patch...


Another point that makes everything different is that MS has contributed to the wine project. They've both sent in code changes to wine itself and they donated mono to the wine project.

> Second, it would be a PR disaster. "Microsoft sues to kill the Steam Deck" is an awful look for the company.

If the alternative is losing the entire Xbox market? Money makes people and companies do funny things.


How is the Xbox market related to SteamDeck? SteamDeck plays PC games (which XBox doesn't), and XBox plays its own console games (which PCs and thus the SteamDeck don't)

The Venn diagram of Xbox games and PC games is very close to the Xbox circle just being completely inside the larger PC circle. The number of Series S/X exclusives is literally zero at this point, at least I'm fairly sure, and if there are any, my bets are on them being shovelware. The Xbox One only has one exclusive game of note, which is Halo 5.

I don't think the performance of the Steam Deck is up to play all Xbox games at Series X quality, but that's a nitpick assuming future Steam Decks arrive.


Isn't the xbox market dead after after having to code for the weaker series s lead to the last generation of consoles being outsold massively by the PS5?

They’re killing Xbox themselves already, I doubt they care anymore.

Oracle lost Google v. Oracle.

It will kill GitHub I suspect. Who will trust them if they can pull the plug on open source projects using the dumb "API is copyrightable" claim? I'd say last time they tried to pull that by backing Oracle in that legal case, they already damaged their reputation enough.

There's no way. GitHub is already pretty hostile, but the only people who care — like in most hostile platform cases — are the ones who are directly affected.

It's a reputational thing. There is already a trend of exodus from GitHub. This Oracle style garbage will just exacerbate it. Whether they care - who knows, but it can be a reason.

But in general - as a developer you surely don't want to host your projects using someone who thinks APIs are copyrightable.


The main issues I'm aware of are whether APIs are copyrightable, and if so, whether implementing them qualifies as fair use.

https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....

(And, of course, Microsoft would also have to consider whether such a lawsuit would have greater benefits than costs. I would like to think that customer goodwill has more than zero value, for example.)


Going back a bit further:

https://en.wikipedia.org/wiki/Sony_Computer_Entertainment%2C...

https://en.wikipedia.org/wiki/Sega_v._Accolade

This fact pattern (reimplementing API functions for emulation or interoperability) tracks even more closely with the Connectix case than Oracle. Google reimplemented a huge swath of the Java API surface so developers could reuse libraries, but actual applications still needed porting, so there's less protection from a fair use perspective; and even then copying APIs was still ruled to be fair use.

I just don't see how Microsoft could contort the facts to achieve a meaningfully different outcome. It doesn't matter if APIs are copyrightable if copying them is fair use for just about any purpose.


I think there are two reasons this hasn't happened: (1) Wine might be useful to Microsoft at some point for providing backward compatibility in Windows itself; (2) it would be an extremely bad look/PR disaster to go after this project after spending so much time and money positioning yourself as an open source supporter

Also, to add the current CEO doesn't care about the OS. All he cares about is the stock price, and his AI mistake.

If anything Microsoft will give up their advantage by making Windows 11 a UX dumpster fire. If Windows 11 had an official way to turn off all of the garbage and opt out of their monopolistic PM-brained “features” a lot of us who switched to Linux probably wouldn’t have happened.

i was using wsl2. and got weird slowness and high cpu. appeared it was their built in antivirus(av). i disabled av, but it autoenabled later and did same. it is possible to secure windows other way without active protection btw.

i used git on wsl2. it got weird issues with git connectivity over wifi. github ticket not solved. one of most popular and essential dev tools is not stably working in wsl2.

many rust crates supported only mac, bsd and linux. nobody cared windows.

so even without ux of recent version, i had to leave.

for my wife is still run windows.

but. she had fully official surface laptop with official office. not 3rd party or pirated things.

and... office became very very slow just typing... it was 3 years ago.

i have run script disabling all things. it good for 3rd year now.

but how they managed to make their laptop new one, with all their things so bad?


This stuff will never ever ever work real and reliably enough for Microsoft to care.

Normal people don't want to use Linux. Normal people can't even install an OS. None the less fight kernel regressions for days.

I can even imagine Microsoft coming out with MS Linux one day and contributing to Wine. That's far more likely at this point.


It does work reliably enough though. A huge portion of games on Linux do so via pretending to be windows via wine/proton. It’s what allows the Steam deck to exist as a product at all.

And Linux on those handheld devices out-performs windows to such a degree that Microsoft has noticed and is trying to make windows perform better on those devices, basically making a gaming mode / handheld mode for their Xbox Ally.


It's not nearly enough to matter to Microsoft. An absolute tiny percentage of desktop computers/laptops run Linux.

This is actually a good thing if you're hoping WINE avoids a legal fight with Microsoft. It doesn't matter who's right, Microsoft has deep enough pockets to drag anyone through expensive litigation.

I'm an active Linux user and I play tons of games via Proton. But this isn't something I'd suggest to normal people. I've spent more time than I'd like to admit keeping Linux working.

They also served as a foundation for much of my career growth. But I understand it's not for everyone.


> It's not nearly enough to matter to Microsoft. An absolute tiny percentage of desktop computers/laptops run Linux.

It matters enough to launch WSL, WSL2, etc. which are the "embrace & extend" part of the strategy.


I don't think it matters very much. It's not a matter of "if" but of "when": one is consistently getting worse, and the other is measurably getting better and more compatible with the former. Unless of a drastic paradigm change, Linux will see more and more users. Trump dismantling of the global system of trade might also add another nail to this coffin (the recent talk by Cory Doctorow at CCC gives a good picture of how and why).

Actually you might be right.

I'm always open to being wrong. At a minimum European governments should switch to a Linux distro based in Europe like Open Suse.

I don't believe this is going to be enough of a dramatic shift where Microsoft would see it worth while to try and shutdown WINE.

This is a good thing though, if Microsoft really wanted to they could sue WINE. Even if WINE isn't doing anything wrong, Microsoft could easily make things really difficult.

We saw this with Nintendo and the Switch emulators.

Maybe I came across as a bit harsh, I run multiple Linux computers, I just can't see this being a realistic concern for Microsoft


> I just can't see this being a realistic concern for Microsoft

I think Microsoft strategy for Windows shifted a long time ago, from being their most precious engineering product, to a necessary component for their sales teams to bundle B2B services. The focus went from "pleasing users and enabling things" to "seeking rent in the gregarious corporate world by building a captive monopoly". I suppose that makes perfect shareholder-sense, but that leaves the door open to a competition that actually wants to make operating systems, in the traditional way.

Now that this model is being threatened, with a real geopolitical incentive to leave captivity and to reconsider past practices (like OEM installs), I think it'd be silly for Microsoft not to immediately course-correct. And that means doing something much more significant than suing Wine: without trade agreements, the US has no jurisdiction and no IP that's worth a dime outside of its borders. That means doing something that, for once, would put them so much ahead of the competition that choosing Microsoft would be a no-brainer. I don't believe Microsoft has it in itself to execute such a thing.


Microsoft has subsidiaries all over the world. They'd still have standing to sue, even if say Germany and France ignored American IP laws( which they definitely won't).

Plus it's not out of the question for them to personally sue WINE contributors. It's not about winning, a simple DMCA takedown notice to any entity hosting WINE code would probably be enough to stop the project.

I want a future of competition between different OSes. I use Linux everyday, but I don't think a market share of 3.86% is sweating anyone at Microsoft.

https://gs.statcounter.com/os-market-share/desktop/worldwide

I could see Lenovo, which is ultimately a Chinese company, making more aggressive steps to offer Linux. But outside of certain ThinkPads you can't even buy a laptop with Linux pre installed.

In my dream world you'd have to buy Windows separately with any hardware. I guess Best Buy could still offer Windows installation as a service though.


> a simple DMCA takedown notice

DMCA takedown has no legal basis outside the US. And it's funny you bring that up: the only reason why this has any relevance at all is because of the established norm for countries to sacrifice some of their sovereignty in exchange for being allowed to trade with the US. Now, with the US breaking trade norms and agreements, those countries can (and eventually will) stop complying, because they have nothing to gain (and everything to lose) promoting hostile foreign competition.


I agree the DMCA has too much power, but I think your getting ahead of what's realistic.

Maybe in 20 years some EU court will declare US IP to be up for grabs, but that's not now. Microsoft is deeply embedded so many different businesses and government IT departments.


With Wine, the main problem is that you may easily encounter some programs that do not work under it, as they rely on unimplemented Windows features.

However the programs that do work, usually work very well, sometimes even more reliably and faster than under Windows itself.

Many older MS Office versions work very well under Wine.

In general many older Windows programs work very well, because the older they are the more chances are that someone else already tried to use them under Wine and eventually any quirks have been fixed.


It already works for gaming reliably enough.

> If you forget to handle a C++ exception you get a clean crash

So clean that there's no stack trace information to go with it, making the exception postmortem damn near useless.


> wxWidgets

I'll trade you wxWidgets for FLTK.

Trying to defer to native widget rendering per platform was a mistake, and every time I've touched wxWidgets in the past decade and a half I've regretted it.

FLTK on the other hand is ugly as sin, but I've found it reliable enough to not act in surprising ways, and it's also small enough to where you can vendor it and build it alongside your program.


Somehow I feel like GIMP's lack of popularity has more to do with its reputation for having a horrendous and impenetrable interface than its name.

At one point in the recent past there was a fork of GIMP named "Glimpse," yet weren't a sudden influx of users who were waiting for a more polite name.


I would say both.

BUT, lack of users might just be that it's too late, now. People use web-based tools like Figma, I wouldn't think a lot of people are looking for a Photoshop alternative.


Krita is doing just fine. It has the subjectively "better" name, but also the improved UX.

We're missing the last part of this quadrant with a Krita-like app that has great UX but a bad name, but the preponderance of the evidence thus far tells me that it is more likely than not that the name didn't matter, or at the very least that the UX definitely did matter while the name might not have.


Complaining about names seems like a surefire way to induce endless bikeshedding conversations that go nowhere. It's also often cited as a too-convenient excuse for why a service fails that doesn't really account for the market realities or whatever systemic failures were at play.

The truth is that 15 years ago, "tweet" was seen as a joke by those who weren't extremely online. It didn't stop Twitter from becoming a desirable place to socialize, at least for a time. If the internet made "tweet" happen, people can get used to any weird nomenclature.


The problem I have with names like BirdyChat is they're not easy to remember and even less easy to explain to someone whose first language isn't English. Like yeah, we know it's "Chat" and "Bird" combined and all but to a lot of people it's just "Bdytsch something". Compare that to Twitter which is relatively easy to pronounce and remember.

Forgejo is even worse in that regard. I live in Europe, speak 5 languages, and still have to think to remember the proper pronunciation every time.

It's much harder to get people on board with yet another messenger app when they forget the name 5 minutes later.


To wit: https://ziglang.org/documentation/master/#extern-struct

> An extern struct has in-memory layout matching the C ABI for the target.

Zig is really good at speaking the C ABI of the target, but the upshot seems to be that it appears there is no stable Zig-native ABI.

If I'm correct, I wonder if there are plans to settle on a stable ABI at some point in the future. I do know that in other languages the lack of a stable ABI is brought up as a downside, and although I've been burned by C++ ABI stability too many times to agree, I can understand why people would want one.


I doubt zig will have stable abi any time soon. It may have some sort of "zig extern" when it gets mature. But stable abi isnt very usful if no-one else can talk it. I have project that uses codegen to effectively implement zig like ABI on top of the C abi.

Heres the kind of code it generates https://zigbin.io/6dba68

It can also generate javascript, heres doom running on browser: https://cloudef.pw/sorvi/#doom.wasm


Andrew Kelley has said relatively recently that there are no plans to introduce a Zig ABI: https://github.com/ziglang/zig/issues/3786#issuecomment-2646...

What's interesting is that the scope of the proposal isn't a Zig-specific ABI, but a codified way of expressing certain Zig concepts using the existing C ABI.

That could be an interesting middle ground.


Yeah the new translate-c package already kind of does that.

Is there a single esoteric DSP in active use that supports C++20? This is the umpteenth time I've seen DSP's brought up in casual conversations about C/C++ standards, so I did a little digging:

Texas Instruments' compiler seems to be celebrating C++14 support: https://www.ti.com/tool/C6000-CGT

CrossCore Embedded Studio apparently supports C++11 if you pass a switch in requesting it, though this FAQ answer suggests the underlying standard library is still C++03: https://ez.analog.com/dsp/software-and-development-tools/cce...

Everything I've found CodeWarrior related suggests that it is C++03-only: https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/...

Aside from that, from what I can tell, those esoteric architectures are being phased out in lieu of running DSP workloads on Cortex-M, which is just ARM.

I'd love it if someone who was more familiar with DSP workloads would chime in, but it really does seem that trying to be the language for all possible and potential architectures might not be the right play for C++ in 202x.

Besides, it's not like those old standards or compilers are going anywhere.


Cadence DSPs have C++17 compatible compiler and will be c++20 soon, new CEVA cores also (both are are clang based). TI C7x is still C++14 (C6000 is ancient core, yet still got c++14 support as you mentioned). AFIR Cadence ASIP generator will give you C++17 toolchain and c++20 is on roadmap, but not 100% sure.

But for those devices you use limited subset of language features and you would be better of not linking c++ stdlib and even c stdlib at all (so junior developers don't have space for doing stupid things ;))


Green Hills Software's compiler supports more recent versions of C++ (it uses the EDG frontend) and targets some DSPs.

Back when I worked in the embedded space, chips like ZSP were around that used 16-bit bytes. I am twenty years out of date on that space though.


How common is it to use Green Hills compilers for those DSP targets? I was under the impression that their bread was buttered by more-familiar-looking embedded targets, and more recently ARM Cortex.

Dunno! My last project there was to add support for one of the TI DSPs, but as I said, that's decades past now.

Anyway, I think there are two takeaways:

1. There probably do exist non-8-bit-byte architectures targeted by compilers that provide support for at-least-somewhat-recent C++ versions

2. Such cases are certainly rare

Where that leaves things, in terms of what the C++ standard should specify, I don't know. IIRC JF Bastien or one of the other Apple folks that's driven things like "twos complement is the only integer representation C++ supports" tried to push for "bytes are 8 bits" and got shot down?


> but it really does seem that trying to be the language for all possible and potential architectures might not be the right play for C++ in 202x.

Portability was always a selling point of C++. I'd personaly advise those who find it uncomfortable, to choose a different PL, perhaps Rust.


> Portability was always a selling point of C++.

Judging by the lack of modern C++ in these crufty embedded compilers, maybe modern C++ is throwing too much good effort after bad. C++03 isn't going away, and it's not like these compilers always stuck to the standard anyway in terms of runtime type information, exceptions, and full template support.

Besides, I would argue that the selling point of C++ wasn't portability per se, but the fact that it was largely compatible with existing C codebases. It was embrace, extend, extinguish in language form.


> Judging by the lack of modern C++ in these crufty embedded compilers,

Being conservative with features and deliberately not implementing them are two different thing. Some embedded compilers go through certification, to be allowed to be used producing mission critical software. Chasing features is prohibitively expensive, for no obvious benefit. I'd bet in 2030s most embedded compiler would support C++ 14 or even 17. Good enough for me.


> Being conservative with features and deliberately not implementing them are two different thing.

There is no version of the C++ standard that lacks features like exceptions, RTTI, and fully functional templates.

If the compiler isn't implementing all of a particular standard then it's not standard C++. If an implementation has no interest in standard C++, why give those implementations a seat at the table in the first place? Those implementations can continue on with their C++ fork without mandating requirements to anyone else.


> If the compiler isn't implementing all of a particular standard then it's not standard C++.

C++ have historically been driven by practicalities, and violated standards on regular basis, when it deemed useful.

> Those implementations can continue on with their C++ fork without mandating requirements to anyone else.

Then they will diverge too much, like it happened with countless number of other languages, like Lisp.


> Then they will diverge too much, like it happened with countless number of other languages, like Lisp.

Forgive me if I am unconvinced that the existence of DSP-friendly dialects of C++ will cause the kinds of language fracturing that befell Lisp.

DSP workloads are relatively rare compared to the other kinds of workloads C++ is tasked with, and even in those instances a lot of DSP work is starting to be done on more traditional architectures like ARM Cortex-M.


> I wonder how many of these (or the Google style guide rules) would make sense for a project starting today from a blank .cpp file. Probably not many of them.

The STL makes you pay for ABI stability no matter if you want it or not. For some use cases this doesn't matter, and there are some "proven" parts of the STL that need a lot of justification for substitution, yada yada std::vector and std::string.

But it's not uncommon to see unordered_map substituted with, say, sparsehash or robin_map, and in C++ libraries creating interfaces that allow for API-compatible alternatives to use of the STL is considered polite, if not necessarily ubiquitous.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: