Hacker Newsnew | past | comments | ask | show | jobs | submit | t312227's commentslogin

hello,

as always: imho. (!)

while i personally really love SQLite for a lot of use-cases, i wouldn't recommend / use it "in serious production" for a django-application which does more than a simple "hello world".

why!? concurrency ... especially if your application attracts user or you just want to scale your deployment horizontally etc. ;))

so in my opinion:

* why not use sqlite for development and functionality testing

* postgresql or mariadb/mysql for (serious) production-instances :)

just my 0.02€


Yeah, I've also found that foregoing Postgres is one step too far. It's just too useful, especially with Listen/Notify making it a good task queue broker. SQLite is great, but Postgres is definitely worth the extra dependency.


You distilled the point well. SQLite is great, but Postgres still hits the sweet spot.


hello,

as always: imho. (!)

hmmm ... i think spring-boot combined with either java or kotlin is a very good alternative to django.

even so i wouldn't compare them directly, but static typing avoids a lot of problems.

idk ... for me personally one of djangos great features is its custom db-model and relative (!) painless db schema-migration.

for spring-boot i often went with the tool flyway for handling db-migration ...

just my 0.02€


hello,

why not somehow try to "replicate that experience" you had?

eg. help / mentor young(er) people who have "nothing" / are early in their careers right now!?

this is what i at least tried to do ... :)

just my 0.02€


hello,

as always: imho (!)

i remember this incident - if my memory doesn't trick me:

it was openssl which accessed memory it didn't allocated to collect randomness / entropy for key-generation.

and valgrind complained about a possible memory-leak - its a profiling-tool with the focus on detecting memory-mgmt problems.

* https://valgrind.org/

instead of taking a closer look / trying to understand what exactly went on there / causes the problem, the maintainer simply commented out / disabled those accesses...

mistakes happen, but the debian-community handled this problem very well - as in my impression they always do and did.

idk ... i prefere the open and community-driven approach from debian anytime over distributions which are associated to companies.

last but not least, the have a social contract.

long story short: at least for me this was an argument for the debian gnu/linux distribution, not against :))

just my 0.02€


But why patch it in debian, and not file an upstream bug?

It’s doubly important to upstream issues for security libraries: There are numerous examples of bad actors intentionally sabotaging crypto implementations. They always make it look like an honest mistake.

For all we know, prior or future debian maintainers of that package are working for some three letter agency. Such changes should be against debian policy.


hello,

as always: imho. ...

idk. ... what do you mean by "managers" in your question!?

in my view: the "real" task of mangers - regardless of the level, but even more if they are at a lower/mid level - is managing peoples & their expectations - either of their "team" or their superior.

and looking at the current state of "AI", i don't see much gain in using it to manage those part of "management".

but i think (current) "AI" would be a good source of "additional" decision/reasoning over the lets call it "technical parts" of mgmt ...

sure, this will change in the future, but currently i don't see much on the horizon regarding the "peoples" part of mgmt.

but in the medium/long term, i could imagine a development somewhat similar to the following:

looking at the progression of neo-liberal capitalism: using / blaming AI for unfavorable (mgmt)decisions may be a good possibility to "hide" behind said AI to enforce such "unpopular" decision.

they would have been made anyways, but using this pattern "nobody" is responsible for such developments, because "AI said so" etc...

just my 0.02€


In my experience with medium to global enterprises, the vast majority of management are paper shuffling, fiefdom building incompetents that through their incessant demands of meetings and reports are actually a hindrance to delivering quality products and services on time and budget.


hello,

ah ... thank you!!

i was searching for exactly the interview with jim keller, which is referenced in the chips&cheese article.

again: thanks for posting the article ... i didn't remember, it was anandtech ;))

"[Arguing about instruction sets] is a very sad story."

* https://www.anandtech.com/show/16762/an-anandtech-interview-...

cheers a..z


hello,

imho. as always ...

its not only colocation of (server|network|...)hardware.

its possible to outsource your infrastructure to a business which "manages" it for you.

idk. think ibm, but also many other larger & smaller vendors who offer such services :)

just my 0.02€


hello,

as always: imho. (!) ...

i remember already many years ago - read: 10+ years - very "common" linux distributions installation medias where provided with kernels which complained about missing the so called "CMOV" instruction - like debian / ubuntu etc. ...

yes, it was easily possible to use either "specialized" distributions or even compile a kernel yourself to run on those CPUs < pentium pro/II/III + ...

which meant: everything up to including pentium (MMX) and AMD K5 ...

i'm not sure: did AMD K6 have those!? i don't remember, wikipedia knows more ... :)

personally i don't care much about hardware which is not able to boot a "vanilla" debian installation medium for its respective hardware-architecture.

just my 0.02€


hello,

there is a version of this article already available at archive.org:

* https://archive.ph/0GcBe

due to cloudflares:

"Error 1027

This website has been temporarily rate limited

..."

just my 0.02€


yay :^)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: