I sometimes need to use gdb to investigate bugs in C or Ada, but it is not my main activity. As a result I will not invest days to setup a debugging environment that I will not remember how to use 6 month later. My solution: I use emacs and have a short note with instructions:
M-x gdb -i=mi exe_full_name -p 29123
M-x gdb-many-windows
set follow-fork-mode child
Yes, yes and yes. ORM are marvelous when you do not know well SQL. With experience, you always end up needing to learn more about SQL. In the end, ORM is as much a hindrance as a help. So instead of spending energy learning the ORM of the day, it's better to invest in longer lasting technologies like SQL.
I know SQL and I like ORMs. For most simple CRUD, an ORM is fine. I don’t understand how they are “as much a hindrance as a help”; using an ORM only adds functionality, it cannot prevent you from using SQL against the data source in the same manner you would if you weren’t using an ORM.
It’s really just syntactic sugar for the subset of very basic queries that are easily expressed in the ORM. If other parts of your codebase are expecting ORM objects, it’s maybe two lines of code to re-wrap your SQL-fetched PK values back into ORM ducks.
When I had to convince my wife to leave windows for linux, the fact that photoshop was working perfectly fine on wine was a huge point. At that time (windows vista 64 era), I was using photoshop V6. It was launched directly from windows partition. All I needed was a "shortcut" file to launch it.
Same for my mother using ubuntu. She do not know her password (the login is automatic). In case of problem, I connect using ssh.
Most of admin tasks are apt-get update/upgrade, rmdir --ignore-fail-on-non-empty Bureau/* (because she creates empty directory on desktop).
The command cupsenable DeskJet-3630-series allows to unstuck the printer without mouse access (I was on my phone with connectbot).
I have changed the computer after 10 years. It was transparent for her.
Blocking downloads of liblzma seems to me to be an ill-advised decision. Now that the mechanism is known, the dangers are limited, but the educational value of being able to study what has been done is real.
While the dangers are limited, they certainly aren't zero. Even if the original attacker(s) have entirely gone to ground others may be scanning for hosts that managed to got compromised by following the bleeding edge and more could get compromised of downloads from primary sources are kept open.
Keeping the affected code visible somewhere could be useful for research purposes, but you don't want it where people or automations might unwittingly use it. If the official sources where the only place this could be found then it might be reasonable to expect them to put up a side copy for this reason, but given how many forks and other copies there will be out there I don't think this is necessary and they are better off working on removing known compromises (and attempting to verify there are no others that were slipped in) to return things to a good state.
Maybe someone needs a year to audit the history and find all the other backdoors. Who's going to work on it for a year for free or without being in on it, I don't know.
hello, at work, I am not admin. I have developed a small flask site using sqlite. Always using commandline was painful. I have considered phpliteadmin, but this requires many tasks for installation. My boss would not understand that I spend half a day on this.
I have discovered SQLite-web today. It took me less than a minute to use it.
This is exactly what I was looking for.
I'd suggest spending a little time with Docker and compose.. even in small, single server applications it helps a lot to smooth out application deployments.
reply