skysight-inc/HackerNews huggingface dataset:
Sorry, I do understand. I think that the particular fortress of highly private communication on a network designed for publishing and dissemination cannot be defended efficiently. I'd be glad to be proven wrong, but my last 25 years of experience with social networks of all sorts, from early IRC and web chats to what we have today tells me to keep my current security stance. Anything on a social network has a very high chance of a public exposure, one way or another.

For the defense in depth / layered defense to work, the initial assumptions should be different. They should be like Signal's, not like Mastodon's. The whole approach should be paranoid about not letting things seep through by any chance at all. I don't think that such an approach would be seen as productive by most users and developers. So, I view various access control settings in networks like Mastodon as a convenience filter, not as a security mechanism.

> not immediately discoverable

This is actually both important and achievable! If you never post your public identity, and things which easily link you to your public identity, it's pretty hard to doxx you and harass you IRL, even if everything you publish were publicly accessible. If you don't advertise your presence where everybody is looking, you have a good chance of not being harassed online, because the harassers won't try hard enough to infiltrate remote corners of the internet.

A reliable pseudonymous identity is a great mechanism, if you maintain reasonable opsec. I just won't expect a great level of insulation of your content from fellow pseudonymous users, and occasionally even from general public.
The cool part about "some local call never fails" is that because of scale out, out-of-order multi-threaded execution, is that even "local calls" (for some definitions of local) can fail as your preconditions get invalidated in other threads, unless you're employing mutexes/barriers.

Those modern computers are a network mesh of small D/G/CPUs, and it's coming back to bite us sometimes.
This is right up my alley.

I'm known for writing documentation that is useful AND, let's say, entertaining. Or, depending on your inclination, sed 's/entertaining/hilarious/g'

Besides docu and Wiki pages (what unfortunately counts for docu in many companies), I've written man pages and shell scripts with more jokes than a longint can probably count.

Once had a shell script that did something really, really impactful and asked the user in increasingly aggressive prompts if he is sure, then delved into existentialism and how he can even be sure that he is so sure. Another prompted the unfortunate victim to validate that gravity, in fact, still works. Long story.

Some have deemed that "unprofessional", especially management. I am elated to see that this has precedence in print, and shall use this to make my case.

Oh, I have writing samples available. If anyone wants to hire a guy to write funny manuals or some other stuff, ping me :D
This article is all over the place. The author acknowledges that microservices are about organizational clarity, then writes "In theory, anyway" without elaboration, and then goes on to talk about the latency impact of network-level IPC.

Why do we care about network latency, when we JUST established that microservices are about scaling large development teams? I have no problem with hackers ranting about slow, bloated and messy software architecture...but this is not the focus of discussion as presented in the article.

And then this conclusion:

> The key is to establish that common architectural backplane with well-understood integration and communication conventions, whatever you want or need it to be.

...so, like gRPC over HTTP? Last time I checked, gRPC is pretty well understood from an integration perspective. Much better than Enterprise Java Beans from the last century. Isn't this ironic? And where are the performance considerations for this backplane? Didn't we criticize microservices before because they have substandard performance?
> Microservices [..] actually solve for a human problem in scaling up an organization.

So does modularity.

"The benefits expected of modular programming are: (1) managerial_development time should be shortened because separate groups would work on each module with little need for communication..."

On the Criteria To Be Used in Decomposing Systems into Modules, D.L. Parnas 1972.

http://sunnyday.mit.edu/16.355/parnas-criteria.html
Quite right, thank you.
> Would it be better if we renamed Python 3 to some other name and pretended it was a completely new language?

Quite possibly yes? It doesn't run python2 code, it can't be inter-linked with python2 code, so is it really the same language? The hybrid dialect that works in both does exist but you have to have compatibility shims in a few places.

By comparison, most C compilers will let you use C89 and C17 code in the same project provided you set the compiler options, and C# provided the "netstandard" target for libraries to smooth the transition between Framework and Core runtimes.
Snow shortage threatens Alps with wet winter season
For the first time ever I had to cancel my holidays due to climate change. I was planning on skiing in the first week of January, not gonna happen.

It was 14 degrees during the day on 31 Dec. 20 years ago it was unusual not to have snow for Christmas and New Year.
Working on a new MLOps tool to manage files, data, pipelines, experiments and models.

I'm writing it in Rust. Using ECS instead of OOP. Going well so far.

It's open (and alpha.) https://github.com/iesahin/xvc

Documentation: https://docs.xvc.dev
If the services need to be in separate data centers then how would a monolith be a solution? Monoliths can't span data centers
>> In essence, the file boundaries ought not to make any difference to this process.

I find this the strongest counter argument. File boundaries shouldn’t matter - but in practice they do.

The ide will give up doing some of its analysis because this is not an optimised use case, the IDE vendors don’t optimise for it. Some IDEs will even give up just simple syntax highlighting when faced with a large file, never mind the fancy line by line annotations.
Some of the services not being in the same datacentre seems orthoganal. If that solves a problem you have, wouldn't it still be an issue in a non-microservices design?
id.me - With the push to get people on id.me to pay federal taxes in the US, I can foresee this eventually being a hard requirement to do anything related to the federal government initially and then eventually required for all state government interactions. Then I foresee this data being "leaked" on purpose to be shared with organizations that should not have it and just like Equifax they will barely receive a wag of the finger.

Network Connected Vehicles - This is already a thing. At best this will result in peoples cars being bricked by skiddies. This can be used to real time control where people can drive. People will have to start paying to "unlock" services in their car that is normally a function of a car. e.g. Get a pop-up that says one has to pay to use the window defogger. At worst this will turn into a dark-web business for targeted assassination or used to silence people that are speaking out of turn. There are some videos of peoples cars doing bad things and the driver fighting for control and ultimately losing. I can only hope more people implement their own private CCTV systems not tied to any clouds to document more of these.

Personal Social Credit Scores - All manor of companies are signing onto ESG believing they will benefit financially by signalling good intentions. Some stock monitoring sites are already factoring in ESG scores. I foresee this devolving into personal social credit scores that would manipulate public behavior and ultimately anyone not aligned with the system would be ostracized from some aspects of society or at least business. This will tie into the above Network Connected Vehicles. Park near a bar and get on a watch list for potential alcoholics. Park near a strip club and your spouse starts getting pop-ups for marriage advise. Walk past a digital billboard and be publicly shamed for being out of alignment with group-think, then be mocked by the billboard when your heart rate increases as per your body monitor. Score goes low, insurance and rent costs will increase, social benefits decrease.

Social Media Algorithms applied outside of the web - Social media organizations have already jumped the shark and many are finally catching onto this. This will start creeping into "smart" devices to manipulate people. Body monitors, smart home systems, AR headsets, etc... Facial recognition will tell the billboards and local businesses who you are, how much money you have and if you are aligned with correct-think. Monitors in police cars will identify people and show their social credit score, who purchases weed, who may be armed as they are driving by.

Network Connected Body Monitors - See Network Connected Vehicles and Personal Social Credit Scores
Would it be a completely ridiculous idea to have a special key that is required (if present) to be to the first entry in a JSON map/object?
Tech Layoffs Are Happening Faster Than at Any Time During the Pandemic
Where do you begin if the code was in hundreds of separate modules? It's not clear if it's easier. It would take time to load the code into your brain regardless of the structure.

By the way, JavaScript parser in esbuild is a 16 thousand lines of code module too:

https://github.com/evanw/esbuild/blob/0db0b46399de81fb29f6fc...
Totally agree.
Also microservices shines IF you need different release schedule for two services. If they are managed in the same project/team, the effort you pay is high, the advantage could not pay your bill, so be careful in such scenario.
Finishing my masters' in Computer Engineering at Purdue University, Indiana, USA this May. Currently on an F-1 visa, with 3 years of OPT + STEM OPT remaining. Looking for full time roles in digital design or software engineering. Spent last 5 years as head undergrad/grad TA for the digital design course at Purdue, ECE 27000, which teaches breadboarding and SystemVerilog, writing and maintaining course software utilizing Python, C++, SystemVerilog, and JavaScript.

Location: United States

Remote: Yes and no

Willing to relocate: Yes

Technologies: Python, C++, SystemVerilog, HTML/CSS/JavaScript + node.js, Flask/Apache, UNIX proficient, cloud technologies such as Google Compute Engine and Amazon EC2, Docker.

Resume: https://nirajmmenon.com/assets/resume.pdf

Email: nirajmmenon@gmail.com
> one of the unexpected consequences is that we are now doing a lot of network calls between these microservices

Not trying to be harsh here, but not expecting an increase of network call in a system where each component is tied together with... network calls sounds a bit naive.

> We are now attempting to solve this with caches and doing batch requests

So you have built a complex and bottle-necked application for the sake of scalability, then having to add caching and batching just to make it perform? That sounds like working backwards.

Obviously, I have no clue on the scale of the project you are working on, but it sure sounds like you could have built it as a monolith in half of the time with orders of magnitude more performance.

Scalability is a feature, you can always add it in the future.
Someone must have read a blog post about microservice and decided it would look good on their resume.
Why Americans with Chronic Pain Are Dying
The irony here is that the person was in many parts responsible for creating XPCOM at Mozilla which was a major reason for the bloat, jumped ship to Apple/Safari at the early stages.

I remember a rigorous article where he dissected Mozilla vs Webkit and explained by why the latter was superior (= less abstractions and no XPCOM). I wouldn't be surprised if that article was the basis for the decision to not go with Mozilla at Apple.

Nothing to be held against him for sure, if you have been in this business for this long you are sure to have created stuff that you realize was not optimal. Particularly over-abstractions.

Also I would not be surprised if it is that person they are talking about in the mail conversation.
I don't think we'll see a version 4 for the next decade or so (because of the python3 debacle) - so it'll probably just be various improvements to the standard library.

There's a lot of improvements being made to Python on these minor versions. So while the version bump looks minor, they can make quite a big impact.

3.11 improved performance by 25-60% (depending on use-case).
3.12 is set to improve performance yet again (Special thanks to Mark Shannon, GvR and Microsoft).
On top of that there's a lot of quality-of-life improvements for the various parts of the std.lib.

I like this apporach very much, since upgrading to a new minor Python version is somewhat trivial
How does it differ from running any proprietary software other than that you can read the script before running it?
> To keep the accounting straight
This article nails it, but I still like microservices because I’ve yet to see a team doing a modular architecture in memory keep from creating a spaghetti mess of interdependence.

Yes, the same often happens in microservices, but the extra complexity of a distributed system provides a slightly stronger nudge to decouple that means some teams at the margin do achieve something modular.

I’m something of a skeptic on modular monoliths until we as an industry adopt practices that encourage decoupling more than we currently do.

Yes, in theory they’re the same as microservices, without the distributed complexity, but in practice, microservices provide slightly better friction/incentives to decouple.
> You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code

.. but you can't use old libraries in new code.
Asymmetric numeral systems – A new approach to accurate entropy coding (2014) [pdf]
> At some point transactional workload volume will grow to what we call "big data" today, and we'll be forced to use more storage-efficient columnar data representations for OLTP.

I wonder.

I built some proof of concept storage using row representations with a novel compression scheme designed to compete with compressed columnar format for space while being fast.

The result is very storage efficient compared with competing alternatives that I started from.

It has fewer writes per stored row than columnar storage if you don't have large batches of rows to write (often the case with OLTP), and fewer reads per full row when doing lots of random access point queries (sometimes the case with OLTP and certainly the case for the application I did the tests for). I didn't compare with a compressed columnar representation, but in theory (there was some compression theory) it should take same or less space in many cases as well as using less I/O.

(It also was neither B-tree nor LSM-tree but had some desirable performance characteristics of both, but that's another story. Not a fractal tree / B^ε tree either, as sometimes people ask that).

Presumably, well-funded groups are out there doing a much better job than I did in my spare time, so I wouldn't be surprised if "big data" OLTP doesn't end up requiring columnar representations after all, or if a scheme such as the one I used ends up competing with columnar formats in the end for space and performance reasons.
The biggest problem is fundamental to Python and a lot of other scripting languages: no static typing. Running Python 2 code direct on Python 3? All looks good, until _somewhere_ you use a method of str that isn't on bytes, or vice versa, or something that was a list before is now an iterable and it blows up in your face... but _only_ if code execution reaches that line. So you have to test _everything_. And if you're a library/module, that means testing with _every user_.

Secondly, it seems to me the Python team didn't want to make it possible to write code that works correctly on both Python 2 and 3 simultaneously. They wanted you to write code that only works on Python 3 and tell every single Python 2 user to get lost. Essentially, they wanted to co-opt you as their agent of change; burn your own reputation by abandoning your userbase (or worse, start proselytising Py3 at them) or double your own workload to maintain two codebases. Who wants that?

It's fundamentally an attitude problem. A desire for there to be only one right way to do things, a change of mind of what the right way is, and kicking the chair out from anyone doing it the old right way; the only compromise being to kicking the chair very very slowly. In Java, you can still run code that uses Vector and Hashtable from 1996, they're not even deprecated. They're used by _very_ little code since generic List and Map APIs superceded them 2004, but they're still there.
The distinct elements are they compile separately and have versioning on their API calls.

No, you don't use separate microservices for writing out that text message.

The idea is pretty simple instead of writing one big program, you write many smaller programs.

It's useful around the 3 to 4 separate developers mark.

It avoids you having to recompile for any minor change, allows you run the tests for just the part you changed and allows you to test the microservices in isolation.

If you a production issue, the exception will be in a log file that corresponds to a single microservice or part of your codebase.

Microservices are a hard form of encapsulation and gives a lot of benefits when the underlying language lacks that encapsulation. e.g. Python.
One of the reasons I have for avoiding the straight reading of 1984 is that the protagonist jumps, eagerly, into such an entrapment. Not a sympathetic look.

But if you want money for people with minds that hate
All I can tell you is brother you have to wait
That's only really true for species that we figured out how to farm.

Species which we eat but don't farm we tend to eat to extinction, or near-extinction. Think of the Atlantic cod fish.
If they hadn’t extended there was talk of actually forking python. Basically people needed a 2.x compatible python, and most features being put into 3 could have been backported. So you’d maybe keep u””, keep print, add futures stuff for folks targeting both and then pull in 3 stuff to reduce pressure to move. They were smart not to drop 2 cold.
ANT plus is PAN for ants
I agree completely, plus there are all the conflicting ways of installing and managing Python programs, dependencies, and environments, and the poor quality of so much Python code, some of it widely used. I find myself having to switch the `python` symlink in my path between python2 and python3 regularly, I look forward to the day when I can purge my systems of all traces of Python.
Not to sound like a crank but it wouldn't hurt to establish them with your friends and family before we may need them, while we still have faith in recognizing their voice on the telephone and can just call them up and chat about it.
Everything will get complicated on large projects. The problem, especially the problem pointed out by GP, is that there is a lot of over-complication in smaller projects ... which is most projects!
It is hard to keep track of the (no joke) dozens of different weird failures each unique instance of this caused. But I do vaguely recall that sometimes, yes, you now have to go and point each individual utility at the right Python, or set an environment variable, or something. Other times you are relying on some combined build package, which if you want the one that has Python 3, no longer includes Python 2. So then you have to go manually install it. But it's no longer provided as an independent install by that package manager anymore, it was just a coincidence that it was still being included in buildpacks-whatever, so now you have to decide whether you want to figure out how to find and install Python 2 yourself or maybe just go and update everything else to Python 3 too or... UGH. Then you remember "Wait a minute, why I am I doing this, I'm not even a Python programmer!"

The worst part is a lot of times, since Python 3 is a breaking change, people decide that it's a great time to finally do all their breaking API changes too, so all of a sudden updating something to the Python 3 version means that all of its associated config files have changed format, and now you're updating config files that have worked great for ages and running into bugs there.
I don't think these "large number of employees" who want to keep working after having their salary slashed 70% exist.
Let's not turn it into penis measuring contents, please. Code organization and requirements differ significantly between different programming niches, and the today's accepted practices are not some randomly invented caprices, but the result of the slow (and painful) evolution we've been fighting through past decades. Each niche has optimized over time for its own needs and requirements. My web apis have hundreds of controllers and keeping them in separate files makes it way easier to manage. I know that because we used to keep it all in a single file and it sucked, so over time I learned not to do it anymore. Does it mean that embedded systems devs should organize their code in the same way? I have no idea, that's up to them to decide, based on their specific environment, code and experience.
Social media (twitter) will get worse due to ChatGPT et al.

One little consolation: Eventually the trollbot armies will waste resources by mostly talk amonst themselves.

Other predictions: Quite a few jobs will be lost: Text editors, translators.

There will be new ethical questions: Is it ok if a Chatbot aids you writing your dissertation? How much is ok? 20%? 40%?

All in all, doesn't sound so great, does it?

Looking on the bright side i am sure we will see creative people come up with great stuff (films, music, images, vr environments, interactive experiences).
Start a fucking blog
Twitter has a similar issue according to Musk https://twitter.com/elonmusk/status/1592176202873085952
You want us to do all the grunt work for you for free? For something that will almost certainly have an attempt at commercialisation in the future? Hmm, no thanks.
Using a euphemism like "chaotic" for an event that would kill hundreds of millions (if it happens globally) and lead to a complete collapse of most social and economic structures is not exactly good form.
Bar exam down. Medical next?

While GPT-3 wasn't advanced enough for cracking medical exam, it was used for notable contributions. For e.g. this is an interesting 2021 paper about "Medically Aware GPT-3 as a Data Generator" - https://aclanthology.org/2021.nlpmc-1.9.pdf

Would love to see if GPT-4 is advanced enough to take medical exam.
as someone that has done a lot of commercial C++ teaching in his time, i would say that this is one to avoid for a beginning programmer. stroustrup is not, imho, one of the worlds great teachers, and i would not recommend C++ as a first programming language. more experienced programmers should go with TC++PL.
Given the life cows, pigs and chicken have, I'd object to the term successful.

They are being reproduced (not a mistake here, they don't actually fuck/reproduce on their own) a lot that's true, but using the word 'successful' to describe their fate seems a bit too cynical.
I just so happen to be looking for a simple-enough morph/"magic move"-based animation software. This looks promising! Especially since I love the style of manim videos.
I've talked to a lot of internationals from less developed countries. "missionary" means "spy" to many of them.
A couple of reasons.

- timing of the influx
- appearance
- my wife is Ukrainian and see believes them to be Romanian. She likely has better insight than I.
- She also talks to them sometimes.

On that note, most recent case of pick pockets I came across were actually speaking Ukrainian in Norwich.
I mean, most vehicle manufacturers don't advertise that their transmissions have a 'reverse' gear but it doesn't mean they can just remove it using a software update...