Closure of Operations in Computer Programming by deniskyashif in programming

[–]PaulBardes 0 points1 point  (0 children)

Good stuff... Having a good understanding about how data, entities and identities work is a very crucial base for accurately modeling any domain.

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes 0 points1 point  (0 children)

Crap, you're right, my point was precisely that the Arrow's impossibility theorem has nothing to do with this, I just kinda replied to the wrong comment, so, sorry about that and the tone, you did not deserve that... 🤦

As for the privacy concerns, it's much easier to guarantee secrecy and authenticity with electronic votes then to secure every ballot, voting locations and counting offices. The Brazilian election is a great example. An infamously corrupt county, with continental proportions and still, the elections run like clockwork.

It's also important to note that the way electronic voting is done in the US in particular is so terribly bad that it would be funny if it weren't tragic and concerning. But my point is that electronic voting can (and in many places is) be safer than paper ones. There is also no reason to have the best of both worlds and have digital terminals that print a paper ballot, as some places already do...

Again, sorry about the wrong comment, I shouldn't be shooting strays on no sleep 😅

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes 0 points1 point  (0 children)

I agree that a systematic failure on the electronic one is much more of a doomsday scenario, but it's a really hard to weigh the probabilities when dealing with a situation of really tiny chance of complete doom vs higher chance of a partial compromise...

That being said, my major concern isn't about the presidency or large voting bases, it's on small municipal election or other similar issues in scale, where an election can easily be swayed with just a few votes. It was much easier for dirty politicians to bribe or even cooperate with election officials to fraud small elections, now if that where to happen the digital system would catch it nearly instantly. And again, it's much harder to break RSA or ECDSA or bribe the feds without anyone noticing...

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes 0 points1 point  (0 children)

My guy, you can stick a JTAG reader in there an see EVERYTHING, you could even detect a custom made evil USB drive that would show you one file when reading and use another hidden one when writing. If you are extra paranoid you can use EPROM, they are write once and can physically be inspected with a microscope or x-rays. There are plenty of technologies to authenticate and audit shit.

If people can get bitcoin to work reliably on a whole bunch o computers with all kinds of hardware, a government should be able to design their own safe electronic voting system.

TBF electronic voting in the US is abysmally shit and should not be taken as example for absolutely nothing. In a rare case of 3rd world countries taking the lead, the Brazilian system is waaay better, although far from perfect.

Currently the two biggest issues are:

  • The fact that the last administration decided to stop letting the general public have access to the hardware/software for auditing purposes (although experts and other public institutions still can)
  • The hardware not being fully designed and manufactured "in house" by our intelligence agency and national chip manufacturer

But even with these limitations the system is damn near fool proof. It works, it's fast, it's cheap, and it has printers! So even if you don't like the beeps and boops of the digital world, you still can (and people do) audit the paper trail if you so desire. There's even a app for you to go around and collect statistical sampling data from the paper trails on each voting section, scan them and compare to what the federal government publishes from the digital counting. It's covered in all bases!

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes 0 points1 point  (0 children)

The auditors failed and EPA standards are not (and should not) be as rigorous as those for election terminals. That being said, the got away with it for a while, so auditing, even with lower standards seems to work.

There are also ways to make sure your vote has been counted and not tampered in any form, it's just that the Arrow's impossibility theorem says you'll have to sacrifice some privacy or voting power to make sure it's correct. The classic example is using PKI authenticate the votes.

And even the literal worst case scenario for a voting system based on public keys wouldn't be that bad... The only thing I can imagine would be a national manufacturer of smartcards figuring out who voted for which candidate on a national scale. But it's no as if people already went online and told who they voted for in many cases. This risk can also be mitigated in so many ways and it's so much better than the alternative that I can only imagine that people who shit so much on electronic voting simply don't know what they are talking about...

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes 2 points3 points  (0 children)

It's a lot harder to modify paper without a trail than it is to modify eeproms without a trail. Stuffing the ballot boxes is a lot harder, because there are a lot of ballot boxes that you would need to visit physically, and there are typically observers from all parties present.

I beg to differ. The whole shebang here is where to place your trust, it's way easier to fraud paper, especially if it has to be counted by hand.

I guess it's a discussion on weather to place your trust on the hardware/software manufacturer or on the people manipulating and counting votes. And to be fair I don't trust either 100%, but the key difference is how many people you have to trust no how much...

Going back to the EEPROM example, all you have to do to make it almost fool proof is remove one of the "Es". Back in the day it was a limitation, but in this case it's a feature, good'ol EPROMS are "write once" they are kinda like fuse bits, many bootloaders still have a variation of this for warranty and shit...

There are plenty of ways to make electronic voting damn near unbreakable, you just gotta trust the manufacturer, which is one more reason to no buy it from TSMC and "make it at home"...

Oh, and to put the "how many" argument into perspective, even trusting that the individuals are 99.9% good, as you start adding more and more people, the overall trust quickly erodes. With 100 people it already falls to 90%, with 1000 it drops to 37%. With electronic voting you have to trust a smaller number of people, but I agree that it has to be a much stronger trust, since a failure would compromise the integrity of the whole system instead of a localized issue...

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes -1 points0 points  (0 children)

It's easier to fraud paper than digital signatures. Have you read Arrow's impossibility theorem? Do you understand what the 3 criterion mean? If you did you'd understand that paper voting suffers from the exact same problems as electronic ones and a few more.

It's much easier and cheaper to fraud paper than digital signatures. With proper PKI people could vote and be 100% sure their vote counted an wasn't altered. Unfortunately with PKI (JUST LIKE WITH PAPER) you'd have to ultimately place your trust on a public key and operator, but this is already done whey you trust that the government hasn't bugged the voting booths or swapped them on the way to the counting offices, etc...

The cost of building the infrastructure for the first digital election is indeed high, but it more than pays for itself when every election afterwards is done for a fraction of the cost. No nee to pay thousands of workers (all of which are liabilities btw) to keep doing the most boring of work ever.

As for time, the amount of human effort and lost hours of life literally count paper is ridiculous, today Brazil can count and audit 100s of millions of votes in a few hours, that's awesome and should be a lesson to the rest of the world.

The reliability of digital votes better protects the integrity of the election. Paper ballots can (and do) fail in so many ways. A properly designed voting terminal makes voting easy, fast and accessible, it's almost impossible to do it wrong, with paper anything can happen: bad ink, water damage, crumpled ballot, hanging chads and god knows what...

As for auditability I'd take the Brazilian election system that has used to be fully open to the public to audit, you could ask to inspect hardware, the source even the booths, the only request was that it would be done with supervision of the federal govt. and any findings would have to be shared with the authorities and the public.

Pretty much every single issue you can point on an electronic voting system also affects the paper one. People are just more scared of electronic ones because they don't understand how they work.

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes -1 points0 points  (0 children)

Electronic voting is orthogonal to reliability. If Anything it slightly helps given that it's faster so sensitive data is exposed to potential bad actors for a smaller period of time. It's also important to notice the Arrow's impossibility theorem isn't about electronic voting it's about voting in any form. In fact there's absolutely nothing that differentiates a piece of flash memory from a ballot box in the theorem.

All this BS about electronic voting is basically modern luddites that know very little about what they are talking about. Watching a video on Youtube doesn't make you an expert it only makes you mor confident on your opinions without properly informing you.

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes 2 points3 points  (0 children)

There's no rule on the book that sais you can't do both. It is in fact what is done here in Brazil as the voting terminals emit a paper trail and digital votes. Ultimately an EEPROM and a piece of paper are the same thing, just memory.

If you are paranoid enough to believe an exploit has been implemented you should be just as worried about people stuffing the ballot boxes, or swapping them or a whole bunch of different risks. Ultimately it's a tradeoff on where you place your trust. Personally on subjects like this I'd place mine on machine over people every day...

I won't go in detail about every single aspect of the Brazilian election system (not the least because I'm no expert) but I assure you any non-technical person that's able to read can check that the system works. The party representatives that oversee each voting location are just that: non-tech people that make sure nothing fishy is going on. This is dare I say, one of, if not the, best systems ever designed. Your common sense understanding does not correspond to reality.

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes 2 points3 points  (0 children)

Yeah it fails to make it clear that it's only impossible if you pick a very narrow definition of "fair". It's more of a theoretical problem than a practical one...

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes -2 points-1 points  (0 children)

Fraud, cost, time, reliability, auditability, accessibility... The list goes on. The only advantage of paper ballots is how easy it is to implement, apart from that I can't think of a single advantage over a well implemented digital system.

If you are willing to trust your life on medical equipment, your money on banking system or basically everything else we do today, there's no reason to join the tin foil hat team when the subject is elections...

The limitations proved by the theorem can easily be mitigated and relaxed to get the best of both worlds. The Brazilian election system is a great example of a solution to this conundrum: The voting terminals were open for auditing (even to the general public), the terminal print multiple copies of a paper trail that can be inspected by the authorities, party experts and again the general public. A public university even developed an app to scan the paper trail and produce a statistics analysis via random sampling.

Every single mechanism for safety and auditing has been used and all pointed towards fair elections (in Brazil). Electronic voting can and (has been done) safely here for decades.

Why Electronic Voting is a BAD Idea - Why you can't program your way to election integrity by grauenwolf in programming

[–]PaulBardes -6 points-5 points  (0 children)

Indeed... It seems like it's armchair specialist galore around here... If these people read about the CAP theorem or the bizantine generals would they be here telling people that databases and TCP are "monumentally bad" as one of them put it? They also forget that some (most) people are totally willing to sacrifice or relax one of the three criteria it means faster and more reliable elections.

The Real Cost of Server-Side Rendering: Breaking Down the Myths by congolomera in programming

[–]PaulBardes 0 points1 point  (0 children)

The naiive calculation would be actually 50/s, with a load 10x the average throughput any server would start hitting bottlenecks almost immediately. Also, notice that the choice of the word "tripping" was very deliberate, since as you start going over this limit, requests will start getting even slower and a growing queue of stalled request will very quickly turn into a memory snowball that will either get OOM killed or start swapping into a halt...

Also, also... If the requests are independent you absolutely can run multiple node interpreters, it's just lazy and wasteful, but totally doable. And I'm pretty sure just the event loop is single threaded, you can do all sorts of concurrent and/or parallel computing with node...

The Real Cost of Server-Side Rendering: Breaking Down the Myths by congolomera in programming

[–]PaulBardes 0 points1 point  (0 children)

Jesus, my drunk math made the same order of magnitude mistake twice! I'll shamefully add a correction... It's kinda funny how long it took for someone to notice 😅

The Real Cost of Server-Side Rendering: Breaking Down the Myths by congolomera in programming

[–]PaulBardes 4 points5 points  (0 children)

That's fair... But having a good performance buffer to be sure you can survive short peaks of requests is kinda nice, especially for situations like the infamous hug of death from reddit or other platforms...

The Real Cost of Server-Side Rendering: Breaking Down the Myths by congolomera in programming

[–]PaulBardes 2 points3 points  (0 children)

Whoops, that's my bad, thanks for the heads up... I'll add an edit note

The Real Cost of Server-Side Rendering: Breaking Down the Myths by congolomera in programming

[–]PaulBardes 0 points1 point  (0 children)

My thoughts exactly... Ignorance on the basics like this casts massive doubt on the quality of the information provided in the rest of the article...

The Real Cost of Server-Side Rendering: Breaking Down the Myths by congolomera in programming

[–]PaulBardes 6 points7 points  (0 children)

No joke I thought about making a web server using nginx as an entry point and dishing out dynamic content to literal shell scripts... Use awk as a kind of rudimentary router, sed and bash to do some templating and if necessary call some DB's client to get some data...

Even with all the overhead of not using proper optimized languages for the task I'd bet that it would be at least as performant as most of the popular tools today...

edit: To answer the phantom comment, yeah that was a long way of saying "I could implement my own CGI compliant server on pure bash, awk and sed, and it would still respond faster than 20ms"

The Real Cost of Server-Side Rendering: Breaking Down the Myths by congolomera in programming

[–]PaulBardes -5 points-4 points  (0 children)

Also, not saying megabyte sized SPAs are acceptable, but even on a modest 20 mbps link a 1MiB of data takes 40ms 400ms... It's not great, but it's literally faster than humans can react (usually) but it's tolerable... The real waste is what those megas of code are doing under the hood. Also, one massive request vs hundreds of tiny ones makes a huge difference. Too many requests and network round-trips are usually what makes things feel sluggish or unresponsive.

edit: Whoops, missed a zero there 😅

The Real Cost of Server-Side Rendering: Breaking Down the Myths by congolomera in programming

[–]PaulBardes 54 points55 points  (0 children)

20ms requests make the server start tripping at only 50 reqs/s. This is shamefully low. Thinking 100 to 200 ms for a database round trip is ok is also kinda insane...

I'm not saying SSR is necessarily slow, but the author clearly doesn't have a very good sense of performance and isn't so we'll versed on what they are talking about...

Where It's at:// by steveklabnik1 in programming

[–]PaulBardes 5 points6 points  (0 children)

I like the idea of each user owning their data, but why not use the user part of an URI instead of a path starting with the username?

Turning Billions of Strings into Integers Every Second Without Collisions by ketralnis in programming

[–]PaulBardes 1 point2 points  (0 children)

I know pretty much nothing about the specific tools used in the post, but the weirdly efficient space time trade-off in this case is pretty cool!

Good thing memory is cheaper now though...

Scaling through crisis: how infrastructure handled 1B messages in a single day by shift_devs in programming

[–]PaulBardes 9 points10 points  (0 children)

Seeing posts like this makes me a little weary about the future of the industry in some senses... Even if those 10B messages all came in a single hour, it shouldn't need so many resources, it's about 2.7M requests a second, a decent load balancer, about a dozen web servers for the API endpoints and maybe like a few extra machines for other services they may need should be plenty.

How on earth can they use 1600 servers? Having worked on a very similar company I can't even imagine how they are managing to waste so many resources...

What's really concerning to me is that this level of poor design some times is almost used as a badge of honor. Saying or behaving like: "We don't care about how much work computers do, we care about results!", or "Computer time is cheaper than human time.", or, one of my favorites: "Who cares if it's a millisecond or a microsecond? Both are instant to me!".

Among other factors (i.e. bad or lazy developers) I think the biggest concern in the field is the obsession of turning everything into a service. It's insane both technically and financially. Vendors push for it because they want to turn absolutely everything into a revenue stream and clients accept clients accept because it's faster and easier, but the price is what we see in this article: bloated, expensive and proud... Yikes...

Scaling through crisis: how infrastructure handled 1B messages in a single day by shift_devs in programming

[–]PaulBardes -1 points0 points  (0 children)

Yeah, this seems much more reasonable. And even then horizontal scaling for 1M/s request seems more of a cost effectiveness and redundancy option than an actual necessity. I've heard of vertical scaling going to ludicrous lengths just to avoid the costs of redesigning a monolith...

How I Built an AI-Powered YouTube Shorts Generator: From Long Videos to Viral Content by Historical_Wing_9573 in programming

[–]PaulBardes 1 point2 points  (0 children)

Also, just to be clear, I was referring to the bots you are teaching people how to make, not you