OP is saying they’ve heard people claim it but hasn’t seen evidence. They’re wondering if anybody has some, because otherwise they’re treating it as a rumor.
I’ve nothing against communists in general or I wouldn’t have signed up on lemmy.ml, but now that I take a look it appears that u/dessalines does maintain a “socalism faq” that includes quite a lot more apologising for Stalin than I would’ve expected and what appears to be some Uyghur genocide denying among many other objectionable things. It looks pretty bad, although I suppose there’s some good stuff in there as well.
To be fair, the political views of reddit, twitter, and facebook management are probably just about as far from my own.
Those factors are what help identify a “tankie”, among other things. Communists are cool, but apologia of atrocities is not an inherent tenet of communism, despite what some people on the sketchier parts of Lemmy would have you think.
Oh no time to cancel Lemmy bcz the founders believe in stupid things. Let's all move to the next thing until those founders are found out to believe in crazy shit. It's free and open source. So fork it.
To add to that, his Georgia indictment is related to his attempt to convince the Georgia Secretary of State to “find” 11,780 votes for Trump, i.e. exactly one more than needed to turn Georgia into a Trump win. Compelling an election official to lie to overturn an election and disenfranchises voters.
His other indictments include the case in New York about falsification of business documents. In order to reimburse his lawyer, Michael Cohen, for the hush money Cohen had paid on Trump’s instruction to Stormy Daniels in order to keep her quiet about their sexual encounter before the 2016 election, Trump billed those reimbursement payments to Cohen as legal fees to the business. Essentially he embezzled from the company. “Allegedly”.
The other two cases are federal charges related to his intentional incitement of/ complicity to the insurrection attempts on January 6th, 2021 in order to overturn the election he lost, and the illegal mishandling and possession of classified documents he took from the white house and hid away at his Mar-a-lago resort and then repeatedly lied to the feds about and tried to hide from them. Most recently, he’s had charges added to his classified documents case for ordering the destruction of evidence related to the case, specifically he asked an employee to destroy surveillance footage that was evidence to this case.
Dumb business law bullshit that shouldn’t matter but does.
Dropping third-party cookies entirely would be a security and privacy boon for users, and the Chrome folks have wanted to do it for a while. But they can’t drop third-party cookies without giving some kind of replacement to the “adtech industry” people. (Not their own ad people — rather, Facebook and the folks who put up the nasty teeth ads.)
Why? Because antitrust law. If Google undermines “adtech” — even though literally no users want “adtech” — then the “adtech” people (possibly including Facebook) will sue them and win. Because in American law, a big business isn’t supposed to directly undermine another big business like that.
Sensible folks should just turn off the ad-targeting setting and third-party cookies.
To be clear, yes, I’m saying that this move by Google is not evil. It doesn’t take away any privacy that users weren’t already losing to third-party cookies from Facebook and other “adtech industry” folks. Rather, it makes it possible to limit how much of your privacy the “adtech” folks get to mess with.
And you and I can already turn it off, and turn third-party cookies off.
And yes, I do think “adtech” is basically a bunch of spammers who (in the words of Douglas Adams) will be the first against the wall when the revolution comes; and that Google is at least slightly better than that.
And yes, antitrust law is, in general, a good thing. This is a weird corner case that, if it had been better anticipated, could have been avoided. It sure would be nice if Chrome were completely separate from the Google business that makes money from ads. Chrome is actually pretty damn good at a lot of things; including (back in the day) getting lots of Windows users to ditch Internet Explorer when it was actively being used by criminals to take over their computers and do crime.
Anyone who tells you all ads systems are a little bit evil is telling the truth.
Anyone who tells you all ads systems are equally evil is trying to sell you pop-ups, spyware, email spam, and worse.
The “adtech marketplace” is a pit of festering corruption that goes way, way beyond anything that you can do with Google ads. There are shitholes out there still trying to figure out how to show you pop-ups just like back in Y2K before pop-up blocking — by compromising your browser security to do it.
I’d suggest anyone who’s interested in what ads systems are actually like, go sign up as an advertiser on Google and then on Facebook for comparison. See what you can do. See what they actually do want to sell you. Don’t spend a dollar; don’t buy a single ad; just see what the product being sold to advertisers actually is. You might be surprised, one way or another.
Like they say, “do your own research”. But not by watching videos that agree with you. If you want to see what these companies really sell to advertisers, go try pretending to be an advertiser. They’ll let you do that.
Anyone who tells you “all ads are equally evil” are rarely selling anything other than a FOSS software they are a part of, but not anything that could be considered adware. Now granted the are shills out there that your should be aware of. Thankfully there are groups that care about your privacy, like Mozilla in my opinion, that give a shit, but not every group is driven by profits.
Hardly a secret you need financial statements for. That google pay mozilla for beeing default search engine. And this is why you all also should donate to mozilla!
Apple never let them in to begin with. If Chrome turned off third-party cookies for all users today, Facebook (among others) would sue and probably win.
Google is rolling out a new feature called “Privacy Sandbox” that also enables websites to use Google’s new “Topics API” to view web addresses in your browser history.
People are generally concerned because it allows a site like Petsmart.com to learn that you bank at WellsFargo.com and that you also visit Nickelodeon.com frequently. Petsmart may then use this information to target ads at you.
The larger concern is that just about any website can learn this information (so not just Petsmart.com, but SouthernRecipeMamaOfFour.net can also get this information, which is excessive access for a site like that to say the least). The fear is likely overblown, though.
What can you do to protect yourself? Don’t use Google products or Chromium-based web browsers.
Edit: Looks like my understanding was off. Shout out to NicoCharrua and a couple other users who clarified that Topics API doesn’t expose URLs, but instead looks at the URLs in your history to create topics (kind of like tags) that other sites can see. Hope my potential employer doesn’t find out about my love of large ethnic butts!
The fear is sometimes overblown, though. It’s awful for privacy, but it gets exaggerated a lot of the time, even in the comment you’re replying to.
(…) enables websites to use Google’s new “Topics API” to view web addresses in your browser history.
People are generally concerned because it allows a site like Petsmart.com to learn that you bank at WellsFargo.com and that you also visit Nickelodeon.com frequently.
This isn’t true. Websites only see some of the topics you visit, so in this example maybe Banking (or something a little more specific like savings account), and comics and animation. Here is the list of topics.
What can you do to protect yourself? Don’t use Google products or Chromium-based web browsers.
It’s a good idea to stop using Google products and Chromium based web browsers, but you don’t have to if you want to avoid Topics API. You can opt out of it (at least for now), and some chromium browsers like Vivaldi, Brave and Ungoogled Chromium will probably remove it from their browsers.
Imo the biggest problem with it (over other types of tracking), is that like RagnarokOnline said, any website can get the info, not just the advertisers. So say, the company you’re working for could be told you’re interested in Job Listings, or Retirement & Pension.
I would say, if anything, the fear is likely under-blown.
Sure, you’ll find many users here on Lemmy who hate what Google are doing… but we’re not the typical internet user. I mean, we specifically found this niche platform called Lemmy rather than use one of the mainstream social media platforms. The typical “normie” who uses Chrome probably has no idea about the privacy risks of using it (either in its current form or when the Topics API is being used). We need to help others understand, and hopefully convince these people to move over to Firefox.
Electron apps are largely irrelevant in this discussion, unless they include a general-purpose browser. The Steam client is exclusively used to display things from some Valve-owned API domain (or is there a general-purpose browser somewhere in there?). All the data generated by Steam is completely separate from the data generated by the normal Chrome browser.
And the same thing goes for Electron apps like Signal Desktop, Atom, VS Code, Slack, Teams, …
No, Safaris engine is called WebKit. It’s different, but they’re related:
Once upon a time there was KHTML. Apple forked it to make WebKit. At some point Google forked WebKit to make Chromium. So now WebKit and Chromium development has diverged from each other over the years.
Anyway, use Firefox :)
Firefox is made by a non-profit for the purpose of making a web browser, it’s not made by a giant corporation for the purpose of pushing ads.
I don’t think that is quite right. As far as I understand it the new feature generates topics from your browser history that website can use for targeted ads. So if you visit banking websites it might add to the finance topic. I don’t think Websites get access to the history. Still it is a shitty idea and please use Firefox.
To add to that, its not just about targeted advertising, but a concern is also what happens to data when (not if) leaks happen and targeted pricing. If someone has frequently visited Nickelodeon.com it could be that they have kids who are already applying pressure to purchase a hamster or bird and therefore the parent is likely to have a higher price tolerance for such a product than a childless person.
enables websites to use Google’s new “Topics API” to view web addresses in your browser history
That’s just false. It generates generic topics from domain names in the history and provides some of those topics to advertisers. Nobody gets to know which domains you’ve visited. It also has measures to make it hard to build a profile on you based on the provided topics.
Any kind of tracking is bad. You don’t have to misrepresent what kind of tracking it is
Some rather big projects started to remove TS, which upset the community. One if not the biggest is Turbo, from the Ruby-on-Rails guy. He said: “[TS] pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard”. Now there is a bit of a battle whether or not TS is actually all that great.
It’s more for library devs when writing their libraries. Using TS means you’re writing in one language and then distributing the compiled version for users.
As users can use things in a lot of different ways you have to do a lot of type “gymnastics” to make your library API as useful as possible.
That means spending a lot of time setting up types when a jsdoc and .d.ts file will do the same thing for library consumers.
It’s really a non issue. If some library devs think they can ship code which is easier for them to maintain correctly, and end users have the same developer experience, then it’s totally cool.
Of course people with no nuance are using this as an argument for why no one should write in typescript (because they don’t like it for some reason). This thread has a bunch of people doing this. That creates drama, but there really shouldn’t be any. TS is bae for me, but I totally get why library devs might want to not use it.
Same, but I come from a C++ background so strong typing is in my blood. This sounds like people who write bad code complaining because the language/transpiler won’t let them write bad code.
That doesn't seem a fair assessment at all. In strongly typed languages the types are part of the base syntax and usually not onerous, but rather straightforward to write. In TypeScript they're tacked on in a way that makes quite a lot of work for developers while also making the code difficult to read and reason about (although good syntax highlighting certainly helps.)
I’ve heard it’s more of a problem on the library side. But I’ve personally had pains with ts when working with quirky features such as enums or discriminating unions. Part of the problem in my opinion is that the types all disappear at runtime, so you lose a lot of the joy of a statically typed language. For example, an API can pass you unexpected garbage and all your ts type wrangling helps not at all.
Well yes, if you don’t take care of properly typing external data, you won’t have it properly recognised. But that’s the same in any language that e.g. consumes external JSON data. Use the tools that Typescript gives you (like type guards) or the tools the community has built (like io-ts).
I don’t do java- or typescript but that guy’s comment definitely translates as “I want to keep on writing messy code and you can’t force me to learn to clean my shit up”.
Same boat: people who hate typescript and therefore ensuring type safety probably also hate unit tests because they are too inconvenient to awesome rockstar developers.
One hundred percent this. It reeks of the kind of ego you get from devs that think their code is so perfect it’s inherently easily maintainable.
I know junior devs that don’t struggle with types and unit testing—any dev that thinks they’re too good for either is immediately sub-junior in my assessment, because they’re clearly unable to write code intended to be maintained by a team.
I know you’re joking, but this isn’t even true. The feedback loop that you get from pre-written tests in watch mode is pretty much instantaneous. This helps me to arrive at the correct solution much more quickly than trying to validate each case as I go.
I think it’s more of a JSDoc > TS thing. I need to check the drama, but I don’t believe anyone would want to write vanilla JS without some type declarations…
Lmao I’ve literally had conversations with people who have asked me to not be as rigorous with unit tests because you have to change some tests when you make a modification to the business logic.
I love unit tests but I hate the eternal struggle behind them.
We should make unit tests so we can tell when the build runs that the app is going to be consistent
Everyone cheers
We lose a sprint setting up unit tests
Oh this one test just went yellow, somebody spends a few hours figuring it out and finds that it’s a bug in the unit test. No no we’re good That’s just a bug in the unit test we’ll plan to fix that in the next Sprint.
Oh look now this unit test is going red we’re blocked. 2 hours later they find out that it’s a real problem but it’s not so bad that it overrides current feature work. Well we’re going to need to override that and we’ll have to fix it in the next sprint.
Unit test failures slowly degrade in priority to try to get feature work done. You end up with a backlog full of yellow and red known problems and no one pays any attention to you that tests anymore.
If I’m writing a Go app with a JS frontend component but then I decide to use Typescript, suddenly I have NPM, Node, and realistically probably some JS build system like Grunt as dependencies of my project.
Basically, it just adds more moving parts to the project when I could get away with a) a simpler build process and b) less separation between me and the browser.
To be fair, I’ve never used TypeScript, but this is what’s kept me from using TypeScript.
You are making a lot of false assumptions about typescript and bringing in a lot of outside problems that don’t have anything to do with the language. Try working with typescript. It is a strict super set of javascript. So if you like vanilla JS, you can just keep writing it, then slowly introduce the syntactic sugar that typescript provides. I did the javascript and coffee script thing for a long while, and typescript is just the better way for most use cases at this point.
problems that don’t have anything to do with the language.
My concerns about it don’t have anything to do with the language. More the tooling that would come with it.
If browsers natively understood TypeScript, I’d use the type-safety features. But I don’t want things like the TypeScript compiler or Node to be a dependency of my build process. Not if the only payoff is type safety.
For your Go code to be useful, you’ve got to set up the Go compiler right?
As much as I wouldn’t recommend it, you can even install the typescript compiler via an OS package manager (at least in most Debian distributions)
At that point (and once you’ve added it to your makefile, or however else you’re triggering your go build), surely then there’s zero additional moving parts needed to compile your front end vs your backend?
Not least of all, I’d argue having a compiler tell me I messed up immediately is a bonus too vs poking around for some time until I get an error in the JS console
I’m definitely not saying I don’t know how I’d go about adding TypeScript to my build process if I wanted to. (Though I might should mention that I don’t usually use any build system that isn’t just straight up part of the Go compiler. go generate specifically.) But it’s one more thing (actually at least 2 more things – the TypeScript compiler and Node, and that’s if you’re not counting the package manager) that I’d need to keep up to date and hunt down backwards incompatible changes or bugs when updating breaks my build.
There are dependencies that are pretty much absolutely necessary (the compiler or interpreter, depending on language, obviously), and if you need a feature badly enough that in practice isn’t worth writing yourself (and isn’t in the standard library), but beyond that you just kindof have to evaluate what dependencies are worth adding and what aren’t. I definitely fall on the side of eschewing dependencies in most optional situations just because adding dependencies willy-nilly has burned me so many times (though I do usually do JS/HTML/CSS minifying).
Meanwhile, build-time type safety isn’t a substitute for (automated and/or manual) testing. And whether the benefits of build-time type safety are worth the drawbacks of having TypeScript/Node/whatever is a calculation everyone has to do. Plus, let’s be honest, there are plenty of other dependences one could add for which the argument is at least as strong as for TypeScript. If you’re using TypeScript, then why not jQuery and Vue and Underscore and Handlebar and Backbone and Grunt and Require and Bower and most importantly these seven jQuery plugins etc? In proactice the alternatives aren’t so much “basically no JS-related dependencies” vs “basically no JS-related dependencies other than TypeScript.” They’re more “basically no JS-related dependencies” vs “a veritable menagerie of JS dependencies.”
What I’m going for here is also about opting out of the samsara that is the ever changing fashion-of-the-week in JS development. And about the only way to do that is to just opt not to use JS dependencies. (Not to say one would have to be absolutist about it. You could say “TypeScript and that’s all,” but if you’re drawing a line, why not draw it one dependency earlier?)
I usually write Typescript with Vue and SSR so my server and client are using the same tooling. If I was writing a basic frontend with minimal JavaScript I would just (and have) use jsdoc for typing.
But let’s be fair, what you mentioned as dependencies are development dependencies and don’t impact the end user (outside of poorly optimized build systems causing issues). Build systems can have some great benefits. Such as reducing file size by utilizing methods such as tree shaking to prune out the unused classes in a CSS library.
It just comes down to choosing the tools to suit the job. Sure, you can use a table saw to cut a stick but it’s probably easier just to use a handsaw. Whereas if you’re cutting a large plywood board you could make do with a handsaw but it’ll take longer and the result might not be pretty.
They do if I the developer am spending time maintaining my dependencies rather than implementing feature X that the end user wants.
Build systems can have some great benefits.
As does not having multiple distinct yet interacting build systems in one project.
unused classes in a CSS library.
I have yet to have a use for any CSS libraries. Maybe that has more to do with the problem domain in which I write than anything. Maybe some day I’ll run into a situation where I feel I’d be better served using a CSS library, but it hasn’t happened yet.
I feel like (and it was created by Microsoft which would support this) the purpose of TypeScript is to make web development palatable for C#/C++/Java developers.
I don’t know, those language are more difficult than Javascript. What makes FE difficult are the libraries and frameworks, and the artistic aspect of the whole thing.
Honestly, it’s a shame that Typescript is used as “a way to make Javascript tolerable”. Its type system is actually very cool and allows for some very interesting expressions and guarantees that are difficult to achieve in most other languages
We should just let the browser execute TypeScript so we can rid ourselves of the JS mess. That would also be the perfect time to do some cleanup of old, abandoned JS features.
Honestly I’m surprised Microsoft isn’t pushing for that already. They already have a decently popular browser (Edge), they own TS, and they have a history with not giving a shit about standards (IE and ActiveX).
Their browser and the V8 JavaScript engine is pretty much Chrome with some bits and pieces. I don’t think they’re ready to add a whole new scripting language just yet.
I think the web peeps are working on adding TypeScript-style typing to Javascript, but only as annotations, so the types wouldn’t actually be checked.
outoftheloop
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.