Nican

Furry - Database Expert - 18+

I am an evil bunny that loves a good mischief. Always looking for ways to cause some good fun, and instigate some chaos. (Boundaries always apply)

My other hobby is databases and robotics. (youtube.com/watch?v=iqA87XYX5U)

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks

2024-11-24

@niloc132 interesting to hear.

I should mention, my project is still alive. Generations of students have updated the project year after year: planner.wpi.edu/

I still find it amazing that it is working as intended. I love strongly typed projects that lives for so long.

I sometimes still work with Typescript, with a relatively overbearing linter, and type problems still leak into the code.

2024-11-24

@niloc132 Hey. I used to do GWT development back in 2013.

github.com/Nican/wpischeduler

I noticed that you seem to actively be developing GWT, and I am kind of curious that it is still being used. How is it still going? Any big projects still using it?

Nican boosted:
indrora, hacker at smallindrora@furry.engineer
2024-11-18
Nican boosted:
2024-08-27

Norwegian is such a beautiful language

2024-08-14

@glitch *hugs*

2024-08-11

@glitch Does not look to be working. Check the drivers.

2024-07-28

@MolarFox @bristle What a beautiful furry moment.

Nican boosted:
2024-07-23
2024-07-11

I still do not get Python developers and numpy.

I had to convert what looked like some really complicated Numpy code into C++. Full of array slicing and transformations.

It ended up being like 8 lines of C++.

2024-07-11
2024-06-01

@Kye @ctcwired BUNNY BUNNY

MUSHROOM MUSHROOM MUSHROOM MUSHROOM MUSHROOM MUSHROOM MUSHROOM MUSHROOM

2024-06-01

@ctcwired Wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf wolf

2024-05-24

@PurpleBooth My favorite pet peeve is people who read some articles online, and then oversimplify every time someone else is talking about a problem.

"Just enable auto-scale"
"Just add indexes to your tables"
"Microservices are supposed to be micro. Just refactor your codebase to have more microservices"

*Hand grabbing invisible throat hand motions*

2024-04-29

@psyolus Step 6: Go back to Sweden looking for gloves next year.

2024-04-24

@dipolecat @rileywd I was looking into it as well- and I was struggling to see the big benefit.

The kernel will generally delay writes to disk unless forced (fsync), and keep files in memory when there is free memory available.

Forcing /tmp to be in memory is forcing your computer to use memory, while it could be dynamic.

And if some other part of the computer end up spilling to swap, you are basically back at writing to disk anyway.

2024-04-24

@rileywd @dipolecat
Hm- sorry for the bad description.

Memory usage of the application is the saw-tooth like pattern, where it seems like it is running a garbage collector.

The application is a gRPC server written entirely in C++, that does some file downloading, some heavy math, some disk writing, and some SQL queries.

I checked the code as I best as I can, and it looks to be following RAII policies. As far as I can tell, all handles are being closed.

I shell'ed into the container, and the /tmp folder is empty, so files are not being left behind. I checked "df", and there is no special mount on "/tmp". There is also no swap.

I guess I need to check the memory usage of the application (using the shell), vs. the memory usage of the container as a whole.

2024-04-23

@dipolecat
Yes. It is a gRPC application written in C++ that is being hosted inside of a docker container in k8s.

K8s allows to define the amount of memory a pod is allowed to have.

I guess heap fragmentation is something that could cause issues, but I am not sure why lots of small tmp files would cause that.

2024-04-23

Q: I have a c++ docker container, and we thought that some tmpfile operations had a memory leak.

We removed the tmpfile work, and the pod stopped growing in memory.

Except we left the code with what we thought had a memory leak running over the week, and when it reached the amount of memory request for the pod, it dropped down to 10%. The pod did not restart.

It feels like there is a garbage collector somewhere, but it is a pretty simple c++ application.

Does anyone have any theories for what it should be?

2024-04-17

@yaldi @ajt Oh- I know. I just really need an evening to make the move.

And then re-configure all of my software...

They all have Linux versions. It is the mental effort.

Client Info

Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst