@retoor tell me exactly how can I secure a computer that I don’t control physical access to

@Hazarth thanks! That’s amazing

@jestdotty since they were introduced, there wasn’t a single instance when they were successfully used to spy on someone/take someone down. Literally not once. It was always some other vulnerability, a much simpler and dumber one on software level

@Hazarth when was the last time you read source code for a tool that you used for personal purposes, and what tool was that?

@netikras but you personally, do you read it?

@Demolishun damn, that one totally went over my head

(b2 is a plane, went over my head, get it?)

@Demolishun with him, it's not just 2, it's #2.

@antigermanist “on every level except physical, I am a wolf.”

goddamn that tastes good. a spoonful of liquid pearl, 200 million living beings united under one purpose. beautiful.

@iiii pure bipolar disorder plus autism. You gotta smoke it all the time every day for at least seven years to get as high as I am.

I agree

Hurry up, you’re late to your Boss Appreciation Meeting

COMMON
LISP !

But the quality isn’t over the top there is it
If you really want over the top quality, you find an American/European/Japanese dude who runs his own custom shop and does it for the sake of it as his hobby on his own CNC machine in his garage. The concepts of product-market fit, economy of scale and marketing in general should be alien to him.
A good example is The New Model F keyboard shop.

@Grumm oh yes. Seeing a bear cub is way more scary than seeing a grown up bear because it means there is a mother somewhere around. Bear mothers act very aggressive and irrational
I never encountered boar mothers, but I suspect they’re just as aggressive

@PaperTrail this one might, yep

@cprn agree. I never extend types at all. Maybe I'm too influenced by being exposed to Clojure at very young career-age, but I would love element.querySelector(selector) to become querySelector(selector[, element]). This is why my "qs" sugar works like qs(selector[, element]), with element defaulting to document.

I structure my programs in the same way: they're functions acting on primitives/built-ins

@Grumm the problem with wild boars is that they're very fast WHILE being burly. That's the same formula as a hippo.

A pistol won't stop it — it's just too big and too powerful. You need a direct hit with buckshot, but those guns are long and unwieldy, they're hard to use when you're panicking.

Your best bet is to climb your nearest tree, and do it fast. Hogs can't climb bc they have hooves.

Not the case with bears though! Bears can climb very well when they need to.

@Grumm man, if there's a lot of them, they're scared and the cage is small enough that you can't adequately fight, it's a matter of minutes that one of your larger veins gets punctured and you bleed out.

Wild boars are terrifying. We call them секач (sekach), where сек- means to cut, and -ач is the same thing as "-er" in English.

In Russian, if something is called after what it does, you know it does the thing really well. On top of that, if the thing being done well is cutting, you stay away from whatever was granted that name.

@Demolishun no, because the analysis of JoyRant shows that it has essentially the same structure as any web app.

@retoor yeah, parsers are legit algos. This is why you write them in C

@CoreFusionX sorry, I confused cpython with that thing that compiles python code into binaries. You're right.

@CoreFusionX don't know about cpython. I say that Python's timsort as implemented will be faster than quicksort written from scratch in C

@Lensflare what do you make at work?

@Lensflare see, oh mister destroyer of clown languages whose code is above us peasants, that your code is mostly boilerplate, and what isn't boilerplate is the same declarative UI which is exactly as declarative as HTML and CSS, plus 20% of imperative code that (surprise-surprise) glues native APIs together and wraps things, AND THAT'S OKAY.

My point was that this is typical and this is okay, in any modern app that isn't an OS core, a compiler or other stuff neither you not me is good at.

Your native Swift app has exactly the same contents as any (nicely written, because your code is quite solid) React or Angular app. The only difference is that yours is written in a more modern language with less footguns that only managed to be like this because it didn't have to provide unprecedented levels of compatibility with 20 years worth of legacy code of all kinds.

@Lensflare

- Profile and user management specific to DevRant

- Weekly rants and community projects features

- Notification handling specific to DevRant's system

The codebase appears to be well-structured with a clear separation of concerns. The high percentage of declarative UI code (40%) is typical for a modern SwiftUI app, while the relatively low percentage of raw business logic (20%) suggests that much of the app's functionality is either handled by the SwiftUI framework or the underlying DevRant API client.

The app seems to be primarily focused on providing a native iOS interface to DevRant's features, with most of the complex business logic being handled by the SwiftDevRant library, which is why the percentage of original business logic is relatively low. This is actually a good thing as it means the app is leveraging existing, tested code for the core DevRant functionality while focusing its efforts on providing a great user experience through its UI implementation.

@Lensflare

Networking and Data: ~400 lines

Total estimated LOC: ~5,000-6,000 lines

Boilerplate Code (~25%):

- App configuration files (Info.plist, entitlements)

- Standard SwiftUI app structure (SwiftUIRantApp.swift)

- Standard iOS app lifecycle management

Declarative UI Code (~40%):

- SwiftUI view declarations in the UI/Views directory

- Screen layouts and navigation

- Custom UI components (LoadingButton, SegmentedPicker, etc.)

- Style definitions and theme management

- Layout and presentation logic

Original Imperative Algorithms (~15%):

- Custom business logic for handling DevRant-specific features

- Vote management and state handling

- Content filtering and sorting

- Custom data transformation logic

- State management specific to the app's needs

Raw Business Logic (JoyRant-specific) (~20%):

- DevRant API integration specifics

- Custom content handling for rants and comments

@Lensflare

— Please scan the codebase and give me the rough breakdown consisting of the following:

1. Total LOC count

2. How much of the codebase can be considered boilerplate, e.g. all sorts of administrative code not directly responsible for the business logic of this particular app and instead common of every app written using the same stack;

3. How much of the codebase is declarative UI, e.g. code fulfilling roughly the same role as HTML + CSS does in web-based apps;

4. How much of the codebase can be considered original imperative algorithms, e.g. business logic that doesn't act as a wrapper to native APIs such as networking or other OS APIs

5. Overall, what percentage of the code is raw business logic that makes JoyRant JayRant?

— Based on my analysis of the codebase, I can provide the following breakdown:

Total LOC Count:

Core app files: ~1,500 lines

UI Views: ~1,000 lines

Screens: Multiple directories with varying sizes, approximately 2,000+ lines

@Lensflare I did some exploring of JoyRant's code with Cursor:

— Do you see the code?

— Let me check what files are available in the workspace.

I can see that this appears to be a SwiftUI project called JoyRant, likely a client for DevRant. I can see several key files and directories:

A SwiftUIRant directory which likely contains the main app code

A SwiftUIRant.xcodeproj directory containing the Xcode project configuration

Standard repository files like .gitignore, LICENSE, README.md, and a privacy.md file

Would you like me to examine any specific files or parts of the codebase? I can help you better if you let me know what specific aspect of the code you'd like to look at.

@CoreFusionX oh yes it will if you write quicksort from scratch in C