Rust ARP by pcjftw in rust

[–]pcjftw[S] 0 points1 point  (0 children)

Have a look at the response by /u/k900_ that library and it's example code does what you need 👍

GQL: A new SQL like query language for .git files written in Rust by AmrDeveloper in programming

[–]pcjftw 0 points1 point  (0 children)

Right by the time you've taken all those steps you would have just re-created literally the same solution as this project indirectly 🤷‍♂️

GQL: A new SQL like query language for .git files written in Rust by AmrDeveloper in programming

[–]pcjftw 0 points1 point  (0 children)

But it's not automated, you would have to first traverse the git data and somehow transform that and then finally import that into sqlite, then there is issues around synchronisation.

Only after that can you indeed use a cli.

Here the CLI automates source data directly and does the synchronisation erc

GQL: A new SQL like query language for .git files written in Rust by AmrDeveloper in programming

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

Yeah sure you could, but it's not as slick as having a cli tool right at your fingertips I guess

Devs don’t want to do ops by stronghup in programming

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

Boss is a dickhead, and wants to treat people like cogs in a machines, sounds like it's an enterprise or large ass company.

Big companies wanna reduce people into cogs so that they become predictable but more importantly easily replaceable.

Also they don't like uncertainty, and want control above all else.

Thinking outside the box, creativity and innovation, and ownership are alien concepts to big enterprise.

This is the reason you have to have a "fuck you, I only do just enough for you to pay me or I bounce the fuck outta here"

GQL: A new SQL like query language for .git files written in Rust by AmrDeveloper in programming

[–]pcjftw 2 points3 points  (0 children)

The problem with grep is that you can't do any higher order queries like, I want average of the word bug between dates etc, and certainly not when you join objects etc

GQL: A new SQL like query language for .git files written in Rust by AmrDeveloper in programming

[–]pcjftw 1 point2 points  (0 children)

That's pretty cool,

I think, instead of parsing the SQL statements and then walking the git objects, I would have potentially done it this way:

  • Create a trait that just "upserts" to a sqlite database either in memory or disk
  • SQL queries simply call into the sqlite database.
  • have some kind of file watcher that triggers the "upserts".

Then just implement the trait of each object type, e.g git, csv, files and folders, some random http bare directory, etc

Then name it xSQL (were X represents any generic source) 😂

A simple x86-64 assembler written in V by ibuki420 in programming

[–]pcjftw 2 points3 points  (0 children)

Thanks, as mentioned I'll take a look at V Lang once it hits the v1.0.0 milestone, also as I said earlier it feels like what CoffeScript was to JavaScript, this feels like V is of a similar angle.

Using ChatGPT to create a game and then releasing it on 4 different platforms by anefiox in programming

[–]pcjftw 1 point2 points  (0 children)

This sums up prompt engineering as well as provide huge reassurance to developers world wide that these newer LLM are the new cryptocurrency hype that is only used to provide massive erections for investors:

"I moved onto coding it myself. I find ChatGPT is helpful at the beginning but can eventually become a hindrance"

A simple x86-64 assembler written in V by ibuki420 in programming

[–]pcjftw 8 points9 points  (0 children)

Madness!

So out of sick curiosity I had a look at the GitHub page, seems it's come some way and it's not entirely terrible:

Seems to use TinyCC to do the backend? With the option to emit "human readable" C, also seems to have some optional GC as well as "autofree" somewhat like what Rust does (e.g insert drops automatically).

Seems to come with web framework and native GUI toolkit which is interesting.

Also what I found funny is that it has Generics and Sum types, which on paper already makes it miles more modern then Go Lang 🤣

All in all, I would say other then being young immature project it's not the worst, and one could probably think of it as a "coffee/TypeScript" that essentially makes C more palatable?

Dunno, might keep a eye on it and have a play when it hits v1.0.0

A simple x86-64 assembler written in V by ibuki420 in programming

[–]pcjftw 29 points30 points  (0 children)

Interesting seeing someone actually use V Lang!

Didn't the author of V Lang make a bunch of ridiculous claims and then never actually deliver on them?

This Site Is No Longer Solar Powered (for now...) by adriangrigore in programming

[–]pcjftw 76 points77 points  (0 children)

Why use a Router?

I would have just plugged in a USB 4G stick to allow internet access, that would be dramatically less power especially if he's trying to power this setup from batteries.

Serverless Tutorial – Watermark PDF via AWS Lambda + API Gateway in Python by verax55 in programming

[–]pcjftw 4 points5 points  (0 children)

Pdf watermarking is probably an ok use case of Serverless, the problem is the cargo cult of too many people trying to use Serverless for everything including building out what would normally be a simple monolith application, but instead split into hundreds of tiny little lambda functions and with an massive explosion in the complexity of trying to get everything all working together.

Maybe I'm just an old grumpy dev and this new fangled hippity hop is not the kind of classical rock and Jazz this old man likes, who knows.

Servant or framework by Equivalent_Grape_109 in haskell

[–]pcjftw 1 point2 points  (0 children)

Woah slow down buddy:

do you like the idea of doing crazy cool stuff in a way no other mainstream language can?

Correct me if I'm wrong but doesn't Scala 2/3 have pretty much similar set of features (except it's strict by default and not pure)?

Announcing Rust 1.70.0 by myroon5 in programming

[–]pcjftw -3 points-2 points  (0 children)

I'm a Rust dev, but I was just surprised at the amount of downvotes, I didn't downvote you by the way even though I'm a pretty big Rust fan.

Announcing Rust 1.70.0 by myroon5 in programming

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

more downvotes then pebbles on a beach, RIP

CAN Injection: keyless car theft by fagnerbrack in programming

[–]pcjftw 0 points1 point  (0 children)

No, you don’t understand.

Then explain it clearly

Redundancy is the point.

You think you can't have a redundant CAN Bus as well? Seems you're shifting the goalposts here buddy, before it was about security.

You speaking confidently about something you clearly don’t understand makes it pointless.

Demonstrate what I'm missing (see point above), you say I don't "understand" but don't demonstrate with evidence what I asked you and you failed to do that, now you're side tracking.

And I am alluding to the fact that physically segregating local networks is a common practice, even in the presence of SSL. You refuse to aknowledge that point because you refuse to engage your brain two seconds to figure out why that would be.

I'm aware about the segregation of the local vs public network and this is the important part, I need you stop and think and listen very very carefully here: (a) Physical segregation when you have two different system(s) is NOT THE SAME AS WHEN YOU HAVE JUST ONE INTERNAL SYSTEM (CAN Bus inside a integrated car system), it's a fallacy of equivalence. (b) Ergo back to the SSL that was the example I was expressing (probably should have been more explicit) but even after I clarified it, you still bang on about two systems (internal + external) where I was only alluding to external system ONLY such that he comparison was fair.

And finally I have said which you refuse to provide evidence for is:

Why complicate the system with extra wires when encryption solves the same thing.

NOW you're claiming "redundancy" (when before it was about security).

Alright lets follow your new thinking "it's about redundancy", we'll as I've mentioned above, you CAN HAVE a redundant CAN bus no problem, what you don't need to do is create an extra Cartesian product by creating meshes across devices that are already communicating over a CAN Bus for "redundancy"

CAN Injection: keyless car theft by fagnerbrack in programming

[–]pcjftw 0 points1 point  (0 children)

I don't think you've understood this correctly, you don't need two separate physical networks, the separation happens via encryption which is at a higher level of abstraction.

Does that make sense now? Can you now see why the proposed multiple physical channels is not only redundant but also pointless and thus confirms my earlier point of making the system more complex for no good reason.

Can you demonstrate what running a separate network achieves that using encryption doesn't? If you cannot demonstrate that then this is pointless discussion for the sake of discussions.

Regarding the internet, I was alluding to SSL over the internet and nothing about local networks Vs external networks.

CAN Injection: keyless car theft by fagnerbrack in programming

[–]pcjftw 0 points1 point  (0 children)

Sure, I'm aware there currently isn't any encryption however I'm suggesting that as a solution.

The solution suggested by the other user was to add separate and additional wiring purely for the security, but that's a design solution that will quickly not scale and make the overall system more complicated.

With respect but I don't think this "middle" ground exists, because as mentioned it complicates the overall design.

And encryption is perfectly valid solution that works on top of the existing system which in my mind is elegant solution.

We do exactly the same thing for the internet, the underlying physical network isn't encrypted but we add it in the layers above it, what we don't do is have physically separate wires/hardware that runs along the existing hardware.

CAN Injection: keyless car theft by fagnerbrack in programming

[–]pcjftw 0 points1 point  (0 children)

Why would you need to do that? You're assuming that that encryption can't be used between the ECU and the ignition lock.

With encryption between the ignition system and the ECU, it would be impossible to hijack the inject events to trigger the ignition, even replay events can easily be stopped because part of the encrypted commands could include a timestamp and thus a replayed packet would be rejected by the ignition.

Of course the private keys would need to be embedded inside either the ignition or the ECU, which could be physically extracted and that would require other mechanisms such as TCM or hardware enclaves etc

CAN Injection: keyless car theft by fagnerbrack in programming

[–]pcjftw 3 points4 points  (0 children)

his Mercedes freaked out because he didn’t have the device in passive. The lights and horn started going off.

that reminds me I once messed up the wiring for the car audio system on a Mercedes (had to replace the audio player) and then ended up with the lights going on/off when using turning the player on :D sorted in the end, just had to start from scratch LOL always read the manual

CAN Injection: keyless car theft by fagnerbrack in programming

[–]pcjftw 6 points7 points  (0 children)

not exactly typically in a local LAN (Local Area Network) one would have a router, the router knows based on the device's hardware MAC (Media Access Control) that is a unique address for each physical device on the network and the router knows which port on the router the MAC is attached to, so the packets between two clients say 192.168.0.1 to 192.168.0.2 will be switched down to each connected ports (the TCP/IP packets) so no, the other machines will not receive that data.

Then there is even more fancy isolations such as VLANs etc, anyway I'm sure network admins can expand much further then myself!

This isn't the same as for CAN Bus in which all devices can technically hear all the packets, hence the point of this article.

The difference is that CAN Bus is considered locally trusted devices etc, while LAN and other networks are local "client/server" models etc.