|
Nothing convection is cheap. You can probably find an all in one ITX for like $700 but it won't be a performer.
To err is human. Fortune favors the monsters.
|
|
|
|
|
more heat = more mass
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
modern fans are really quiet.
My new computer has 2x input, 1x output and 2x (fractal design pop air case) on the cooler (bequiet cooler)
Games will push them up, but they stay quiet.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Eddy Vluggen wrote: I do not want any moving parts in my next desktop.
No fans, not anything that moves. And it needs a 3d card with the same restrictions. And cheap, please.
Will this do?
|
|
|
|
|
Eddy said that he doesn't want any moving parts! Those beads definitely move!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Also, an abacus when operated is far from noise free.
|
|
|
|
|
Well if it makes any noise it's your own fault for slapping the beads around.
|
|
|
|
|
|
No good. The buttons move when you press them.
Also, while RPN has the advantage of not requiring parentheses, I never really got to like it.
English version: HP-41C - Wikipedia
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I had also my problems with RPN at the beginning. But after a while I began to love it
Thanks for the english version of the link
|
|
|
|
|
I suspect that HP41C was created to alleviate a problem discussed in an article in 'Journal of Irreproducible Results' (JIR) around 1978-79:
The recent popularity of electronic calculators may lead to a shortage of numbers. As everyone knows, when your calculator displays a number, and you turn off the calculator, that number is gone forever, and can never be recovered. That number is lost.
The problem is not as significant for real numbers, as the set of reals are of infinite size, even for a short value range. For integers, the problem is much greater: The number of integers lost this way could mean that we in not too long will be out of numbers e.g. for paginating book, identifying building floors and several other essential applications of integers. We should immediately establish an international program for saving the integers, and establish a register of not yet lost numbers, where those with real, justified needs can apply for still available numbers or number ranges. Until this Save the Integers program is established, owners of electronic calculators are urged to keep them permanently turned on, so that no number is accidentally lost.
The good thing with the HP41C was that no number was lost when you turned it off
The article was published in the pre-web age; JIR was a printed journal only. Our University Library subscribed to it, but I doubt that they'd be able to dig up 40+ year old issues from their archives. I sure would like to read that article again, but have not yet succeeded in finding JIR archived on the internet. If anyone has seen it, please give me a hint! (A.k.a URL)
|
|
|
|
|
Gaming machines trend to be bulky. with lights all over so you know that it's good.
The majors everyday pcs are so light and quiet it's ridiculous, with the internal power supplies often being superseded with lump in the line transformers.
If you're not coding for a game there is little need for the heft today.
|
|
|
|
|
I must agree. My main machine is an i7-6500U with 16MB of RAM. It is quiet, and does everything I need it to do.
Extreme speed is unnecessary - I'm either writing code (in which case it responds at "human" rates), or debugging code (in which case the required response is even slower). If I were a gamer, or writing games, I'd obviously need something more high-powered.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
But what about the lights? Can't forget the lights...
Jeremy Falcon
|
|
|
|
|
|
He also did Chariots Of Fire[^] - an excellent movie, slow and thoughtful - well worth seeing if you missed it.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thank you Sir
|
|
|
|
|
|
...DI (Dependency Injection) and especally DI Containers.
I'm meanwhile tired of reading and thinking about it, or then most probably I still don't get the point on it.
Basically, the concept of DI, I like it very much. It forces me to think about my design. And yes, it supports me to write (independent) unit tests. So far so good.
But what I hate among others, is a sentence 'program against an interface and not against the implementation' (abstraction vs. implementation). Only the word 'against' is wrong in my understanding, but that is most probably my English...
Sorry, but at the end, when it comes to assemble to so called loose coupled things, it has to work with the implementation and not with the definition of the interface....
I think we always need a real test again, which tests the loose coupled thing against the concrete implementation.
Where the hell I'm wrong?
|
|
|
|
|
0x01AA wrote: 'program against an interface and not against the implementation' (abstraction vs. implementation). Only the word 'against' is wrong in my understanding, but that is most probably my English... The phrasing is awkward, even for an English speaker.
Another way to phrase this would be: "Program according to an interface, rather than based on an implementation".
Does this help?
Software Zen: delete this;
|
|
|
|
|
Thank you so much. yep, it helps a lot.
|
|
|
|
|
"Program against" as in the context of defensive programming. He pretty well says "always use an interface" instead of the actual object (the implementation).
Before "DI" we had parameterized constructors; which is now "DI"; that's why there's confusion. Making up words to fit the model.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
|
Think of "against" as in the context of a ladder leaning against a wall.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
DI is overrated. Programming "to" an interface is fine when you have a real use case to abstract different implementations that you may want to switch between when service A (or controller A) needs to support service implementations S1, S2, and S3. For example, you might have several document store services, one for AWS buckets, one for your own document server, one for storing documents as blobs in a DB and different ones get instantiated on the fly depending on other factors.
That said, one can code an application into interface hell, where everything has an interface and almost nothing needs an interface because there's only ever going to be one concrete implementation of the service.
Happily, in .NET Core for example, the DI engine doesn't require interfaces - you can specify "this service is implemented by its concrete type" rather than always having to say "this service implements this interface."
I have literally chucked out thousands of lines of interface code (I pity the programmer that wrote all that crap -- it wasn't me) because they were glommed onto the "DI must be done with interfaces" not realizing they were making pointless work for themselves because the never ever would have multiple concrete implementations for the interface abstraction.
Know when to use an interface rather than always use an interface. Much like, um...
|
|
|
|