Posts by vincent himpe 686 posts • joined 13 Aug 2006
Something like a physical thing ? like bits of paper with pictures of dead presidents (or other people) and a few watermarks hidden . If i hand one of those to you , you can't steal more of mine as they have no relationship to each other. Maybe someone should invent one-time-use payment tokens.
The point is that people CAN read the sourcecode, but DONT. Concept of a library : a chunk of code ready for reuse. When you go get a book from the library , do you check nobody has inserted some additional pages ? changed a paragraph or two ? No, because it's hard to do that in a book. Should be the same with code libraries. Keep it open and accessible and readable but lock it for 'write'.
i implied nothing ! Having the sourcecode is good. I am merely highlighting the issue that 99.9% of the users work in the following mode : i need to do xyz , is there a library ? yes ! , download , study API and figure out how to use it to solve their problem. They don't look inside. In an ideal world they should not need to. That is the principle of a code library. A chunk of reusable, vetted code, maintained by a gatekeeper. I am a librarian (for a corporate CAD library). Every day i have to fight off the hordes moaning why it takes so long to 'release' something to the library and why can't we change xyz, it would fit better for their application. it's only a small change... Well , it would, but it would also break hundreds of existing designs ! if it is a mistake : we will fix it. If it is an inconvenience for you: live with it, everyone else using it is happy. Every request leaves a revision trail that is fully documented about what was changed and why. Only two people can alter the library. Parts go through a vetting process where their status is elevated from Design , to prototype to production. Only when a prototype has been built and verified to be correct does it get released. The end result is a library of parts you can trust to follow their specifications. That doesn't mean they are usable for your application, it only means they follow the specification. A new revision means there was an alteration to the specification.
The library behaves like a WORM (write once, read many) any alteration is logged and cannot be removed (you can undo it, but you cannot remove the previous one. it leaves a trail and the data is there to inspect. No committing something, then removing it and posting an updated version. You can only post newer versions.
The current model does not work. You can state that the end responsibility is the end users, but that too is bogus. You cannot expect every developer to understand ever line of code in the application he is working on.
The whole intent of a library is to reuse and speed up development. For that , the library needs to be trusted. And that is the pinch point. Too many people can fuddle with the libraries. Each library should have a closed group of maintainers and only they can post updates.
This lack of gatekeeping , combined with the popularity of library xyz makes them enormous honeypots. slip in some malicious stuff and let it spread. Nasties used to be small binaries dropped into a working machine, now they are lines of source code hidden in public libraries.
first : Apparently some people did read it and found this issue, kudos to them !
The bigger question is : why did it not get read BEFORE the commit. It makes me wonder if / why there is no gatekeeper. This distributed review process does not work. Banking on the users to review the libraries is an utopia. 99.9% never read the source packages, they got enough work with their own development , let alone inspecting and understanding the inner workings of a library. That's why you get a library in the first place ! if you have to spend time going through the entire library's code, you may as well build your own library. And every time there is an update you can start over.
There is no responsibility for OSS. Any time there is an issue there is a bunch of handwaving and a statement along the lines of "it's open source, you can read it". Basically use at own peril.
Because of the widespread usage of libraries, and the lack of centralized vetting, this is a tremendous honeypot for miscreants.
Of course i will get flamed for this, as it exposes a big painpoint. Yes we got the source, but in reality, who reads it ?
It took em 25 years to scrape enough money and get enough parts to cobble this thing together. Once launched they find out the engines don't work when they need to , and work when they don't need to. Someone mixed up two red wires ? Ditch the damn thing before it does more harm.
Waiting 20 minutes while charging is a loooong time, fueling up is so much faster.... except they go stand in line for 40 min's at costco cause the fuel is 10 c/ gallon less. And they keep the engine running while standing there , cause, you know, ac and all that stuff.
My average daily time spent charging is close to zero. That is , the time i have to be actively involved in the process.
Fueling up requires active time usage on my part : driving to a station, waiting in line, waiting while it is pumping the fuel, more time spent while paying at the terminal.
With electrical that is a non-issue. Whenever i am home it is plugged and charging. Solar during daytime, from my battery storage at nighttime or from the grid. I do not have to sit there and wait in line. I plug it in and go do other things.
Same thing going to work : arrive, plug it in and go work. (OK, not all employers have chargers yet but that is coming. Just like every parking lot in scandinavia has engine block heaters)
On the occasion where i do a road trip that requires a charger : i plug it in , get a coffee , go do number 1 or 2 , grab a bite to eat and i'm good for another 4 to 5 hours on the road. After 4 hours of non-stop driving it's time for one of the aforementioned activities anyway. And those activities are long enough ( Starbucks can get very busy and you spend a good 15 minutes for a cup of joe .. ) that there is (almost) no 'idle time waiting for the charge.
of course it is not your bog standard graphite .. although that actually performs very well.
If you find a metallic foil with black slippery , semi shiny surface that can be scraped off ( kind of like those scratch-it lottery tickets) : that is a graphite based TIM. Intel uses (or used ) those for awhile with the XEON processors.
https://industrial.panasonic.com/ww/pgs2/soft-pgs
That site has nice graphics and shows some easy to understand basic principles and problems with grease (like the pump-out effect)
Initially i was not very keen on the Arctic stuff as i could not find a real datasheet that shows measurements and compound composition (the composition is typically published in the SDS : safety data sheet).
Anything that has not "measured according to a standard procedure" engineering curves, and data, is useless. You can't compare it. My product floats according to the brick test. But that one there is better cause the cat prefers sleeping on it.
But, i found it: https://www.arctic.de/media/bf/b7/b1/1597063298/MSDS_MX-4_EN_20181026%20English.pdf
It turns out that this is a combination Alumina 50% / diamond 5-10% blend , hence the better performance.
The gizzly stuff is only alumina and zinc oxide. They don't publish any real technical data(at least none i could find). Just a statement "as tested by overclockers guide" which means nothing. This is akin to "The cat likes it". Since nobody knows the cats decision making procedure it is useless.
If they are properly bolted down they will not move. That's why these heatsinks are spring loaded. The thermal expansions and contraction during the heat cycles need to make sure you don't break the barrier.
The elasticity of the pad compensates for that. The same goes for the thermal compounds ("grease" as it is wrongly called). There remains enough of carrier to allow for this. The stuff is at the same time tacky enough and elastic enough it can overcome this movement without issue.
If you gave it a whack , and it shifted .. by all means replace it. Then again ... what nutcase gives the heatsink a whack ?
The space shuttle issue had nothing to do with moving. The o-rings became hard when it was cold and lost their elasticity. As the booster ascended the gaps between the stages widened and the rubber o-ring (actually not rubber. They were Viton (tm) (a fluoro elastomer) made by Morton Thiokol.) could not compensate. It becomes rigid at low temperatures could not expand fast enough, leaving an opening where gas escaped with the well known resulting explosion. Vibration had nothing to do with it.
Your laptop ,amplifier or graphics card is not subject to nearly such strong mechanical forces.
The Registers is a good publication, but once in a while they totally do a cock-up. Especially when it comes to the deeper points of engineering. And that is not entirely their fault. The internet is full of half-truths and misguided information. We live in a cargo-culture world, where even schools propagate cargo-culture.
When;s the last time you went "Ok kids, let's all gather our amplifiers and other electronics today. It's time for the annual thermal grease swaps on the power transistors..."
That is just not being done. Why would you do it on your graphics card or laptop ? I've got equipment (Hewlett Packard test equipment) that is 50 years old and still has the original paste from when it was built. Works perfectly fine.
If you break the thermal interface because you needed to remove the heatsink or replace a component, by all means wipe the damn thing clean and reapply , sparingly, new thermal grease.
And don't fall for the oxygen free reverse electron spin tinseltown compounds they charge 20 times the price for.
Stick to the known brands like Parker , Laird , Loctite. The good stuff is around 3 to 4 watt metre-kelvin and around 250$ per kg. So a 10 grams tube should be about 2.5$. Some of the fancy-pants stuff ( which is nothing but repackaged of the above. There's ain't that many companies that make this stuff) sells for 10 times that price !
Laird Tputty 508 , Parker Chomerics Therm-a-form have been the staple for many decades.
I've been in electronics for almost 40 years of my life ( i etched my first circuit board when i was 8 years old) and it boggles my mind if i read some of the stuff being pushed out there.
replacing thermal pads because they 'age' ... total and utter nonsense !
Do they leak an oily substance ? yes, some do.
Does it matter ? no, not a bit.
Thermal pads or thermal grease is an emulsion made from alumina (aluminum oxide) suspended in a carrier material.
The thermal properties are determined by the alumina. The rest is just a carrier to be able to manipulate it.
You only need very little paste. Heaping it on works aversely. It is not a refrigerant. It's a transfer material. One that has worse properties than then materials it is trying to transfer between. Yes, you read that right. The heatsink and the copper slug on the device have much better thermal properties than the alumina.
Why do you need it then ? because, at microscopic level, neither the heatsink nor the heatslug on the device (processor,gpu) are 'flat'. They contain pits. The thermal compound fills these potholes and lowers the thermal resistance. When the device goes hot for the first time the "oil" goes fluid , the alumina particles settle under pressure and that's it. Components mounted on a heatsink where paste is used will always be mounted "spring loaded", either by special retaining clips made from spring steel, or using split-washers under the screw, or the heatsink itself spring loaded. the reason is what i came to mention before : at first operation of the assembly, the first time this stuff gets hot, the oily carrier goes liquid , squeezes out, while the alumina particles remain trapped. the carrier material is a very bad thermal conductor, you want it out of there.
The same nonsense goes for statements like "this paste is totally dried out , let me replace it".
It MUST be dried out ! That's when it is most effective.
Aluminum has a thermal conductivity of 230-ish watts per metre-kelvin
Alumina is 30 ...
Copper is 401
Oil is 0.1
Now you get it why you want that oil out of there ?
As for the thermal pads : they need to be compressed for the same reason : get the carrier out of there and compress the TIM ( thermal interface material )
There is a tendency to go away from alumina based materials and go to carbon based material ( a material called Vertical Carbon ) or graphite.
Carbon, under certain circumstances, is a much better thermal conductor than most other materials out there. Diamond, which is the crystalline form of carbon, can handle 2000 watts per metre-kelvin. Nothing else comes close to that apart from graphite. There are some exotic materials such as magnesium oxide, boron nitride and aluminum nitride that perform very good. Some of these are actually used inside the semiconductor package.
And yes, you can actually buy thermal paste that uses , industrial, diamond . It is used in cooling applications for high performance lasers and processor modules like for IBM Z-series mainframes.
i still cannot understand why C is such a popular language. C was designed for a register based processor (pdp-11 is a register based architecture) . x86 is NOT a register based architecture. The damn thing fits like pliers on a pig. C on ARM (or 68k or powerpc) produces much better and denser code than on x86.
let's run an interpreted language on a virtual machine that runs on another virtual machine and shoehorn that onto another virtual machine that runs on an operating system... that may sit in another vm ...
Gimme back my 8k floating point basic interpreter that ran directly from ROM. Those were the days... i'm getting old. we need 5 billion transistors and 500 megabyte of code to print hello world.
a billion transistors and a million lines of code for a lightswitch...(those wifi thingies are almost all esp8266 based. that chip has several million transistors, add the ram and rom you hit the billion) and it could all have been done on an 8051 with 4k of rom and 128 bytes of ram...
jup. there's only about 4 million speakers of real 'flemish' and then there are like 300 dialects.... The rest is Dutch and some south afrikaans (but that is so altered it is a language on its own. Even real 'dutch' is hard for flemish speakers.
The toughest to deal with are the chinese. When in a meeting you need to come to a conclusion and they answer 'basically yes' ... that can mean any of the following
- we have not understood a word of what you said, but we agree with the provision we may alter anything and everything later.
- we agree but we can't tell the higher ups, as that would be impolite , so we don't agree
- we don't agree with anything at all. So 'basically yes' , which translates to 'no'
yup. as a deuteranopy sufferrer myself (red/green colorblindness) i lost count on how many battery chargers i have taken apart to replace those red/green ( in one package) LED's with red/blue contraptions of my own ( two 0603 leds and three recycled resistor pins)
cable/dsl router/ modems are the worst. they have like 8 led's and call all blink red, green or red/green. grrrrrr.
We all need to go through those body scanner yes ? Have a built in scale in those. Walk up, insert your ticket , As you are being scanned you are being weighted. your ticket comes out the other side. The scanner takes a snapshot of your ticket and can correlate the weight to the ticket. the computers do the rest . Anonymous as nobody gets to see the individual numbers except the total for the flight by the pilot.
69kg's ? have you looked at your average couch-potato these days ? they better have a 100% margin of error on these calculation programs. Fancy a flight full of pensioners in their floral-curtain dresses like 'Violet and Daisy Bucket' and their pot-bellied 'Onslow style' husbands ... not a chance that falls in the 69 kg range.
Back in the good old dos days the boards also had jumpers to do the address mapping. And the config files needed to match the settings. That kept the riffraff out of the mashinene nicht gemacht fur das gefingerpoken un mittengrabben. Der dumbkopfen mussen keepen their hands in their pockets.
Those were the days a sysadmin always carried a boot floppy and a screwdriver. Now all they do is sit behind their screen coffee slurping while remoting into a machine somewhere halfway the globe.
bingo ! We are still stuck in a world where the compiler needs a ; to figure out the end of statement and cannot derive when = means 'assign' and when it means 'compare'. Both problems were solved in languages much older than C. The problem is the people that developed the c parser. Their coding skills were only mediocre. That is now the standard we have to deal with... The same goes for null terminated strings. You are banking on the presence of a marker. If that marker does not come the thing goes wonky. Strings should be arrays with a header describing their size. You cannot read past the end and the end is known before the first character is read. The same misery happened with integers. It depends on the hardware what size they are. That has now been solved with uint32 in32 and other types.
Nope. there's more embedded stuff in the world that can't even run linux than there is that could run linux . The brunt of this 'snot' has 2 to 16 kilobytes of rom and 64 bytes to a few k or ram and clocked at 16MHz or below. Even the more advanced 32 bit systems do not have enough flash or ram or a MMU to run linux. look at all the Arm Cortex machines out there, by far one of the most popular embedded platforms right now. and lest not forget all the microchip , avr and other architectures in the 16 and 8 bit domain. the bulk of embedded systems run no operating system, have no connectivity ( internet - wise ) and no UI to speak off ( apart from some buttons and a few led's maybe or a small alphanumerical display. even with touch screen graphic displays they don;t run big os's like linux.
Z-wave is the solution
- no central command and control server, especially not a shady one in farawayistan that may go bellyup when the company goes defunct.
- intelligence and routing happens in the node.
- no 50 million transistors and 5 gigabyte of code to turn on a lightbulb which nobody understands anymore
- no enrolling in the network without a physical operation ( mechanical button press)
Gen 1 had some issues with a vulnerability due to firmware downgrading. Gen II solved that.
My biggest worry about those things like SONOFF and others is that, if the c&c goes down your system is dead. Or, if someone hacks the c7C server they can play blinkenlights with your stuff...
Not possible with a z-wave system. unless you are physically in radio range of my network, and you have and enrolled device you can't do diddly squat. To enroll your device, i need to press a button. which ain't gonna happen as i don't trust you.
i don' t care what the underlying kernel is. An operating system is a piece of code to do housekeeping and provide services to applications ( windowing, gui , storage management , printing spoolers etc ). You don't "work" with an operating system, you work with applications that run on it. Right now the OS is chosen in function of the applications. It would be nice to not have that problem.
An API is typically a list of function names and their arguments and return values.
void do_something (void);
int16 add_two_int16 (int16 a , int16b );
...
and so on
That is NOT code. That is just prototype function definitions.
This would be like you: Here is "English", we patented all the words and the way you use them.
In an environment where everyone was running Solaris on Sun workstations and we only had a few ( like 3 or 4 ) Pc's running windows 95.
We need to create backups of the data ( mainly sourcecode) on the PC , so a Samba share is opened on the big file server.
One day we discover that all files coming from the PC are stored as ROOT. What the hell ? IT panics , changes root passwords. no solution. New incoming files still appear as root..
What has happened is that, on the windows95 pc someone had just created a user called 'root' with password 'root'. When connecting to the samba volume that machine asked for credentials and went : oh you are root ? ok then ....
With a few mouse clicks i could move entire directories , including the operating system itself .
Took a while to get that hole plugged.
Open source community complaining that they have been giving the source ...
Which leads me to this : if this driver is 'too large' , how is average "joe user" supposed to scan the entire operating system ?
Next time i get the an answer along the lines of "it's open source, you can check it yourself" , i will point them to this driver ...
"The whole industry seems to be burdened with languages that need semi-colons and squiggly brackets to tell the compiler what the developer means - it's so 1970's! "
My thoughts exactly. Why on earth do we need a semicolon ? there is a line terminator in the form of CR or CR/LF in the source file.
yeah yeah i hear you , end of line is not end of statement. How many times do you spread a statement across multiple lines ? use a continuation character instead.
Same nonsense for case sensitivity for variables and keywords . urgh . Fortunately we have cleanup in the code editor, but still. I Hate it when i have to dig through code that is written as x+ = x+X;, wtf ?
write readable code. in that respect VB is still the best as it uses understandable keywords.
For what it is worth : i am not a programmer , but i do need to write scripts and code to interact with other tools ( mainly CAD) , cronch some tables in excel and whatnot. VB is a dream to work with.
also : in Vb you can stop a program mid run , alter some variables, insert some code, move the execution pointer and continue the run WITHOUT needing to restart the program .
I haven;t checked , but do the othe rlanguages support that ? especially insertind or altering code and moving the execution pointer to re-run or skip a section of code .
I don;t understand why this banks on a server. When i store passwords : they are stored on their machines ?
It's time to have a piece of hardware to store passwords. Like a usb stick ,or bluetooth box or phone app. something that does not bank on the cloud but stores the passwords in the machine. One master password then can access the stored data. And there needs to be a way to backup and replicate if the piece of hardware dies. Like an encrypted file that can be simply dragged back to the piece of hardware.
does that exist ? if not : business opportunity.
i have an old Daewoo dvd player i bought at Sams club in the year 2001. It has a hard mechnical ppower switch ( none of that 'standby' business ) and uses a real transformer (none fo that switching mode power supply crap). Between -click- of the power button ,splash screen and disc playing it takes all of 3 seconds. The entire firmware resides in a 128Kbyte rom.
The latest and greatest bluray takes 25 seconds to chew on the same dvd disc before you get the disc startup. That is, if there are no 'mandatory' firmware updates inbetween.
I have the bluray around for some movies that are not available on streaming. Once i find those i will retire the player, take it out back behind the shed and use 'lucille' on it. Its remains will be doused in gasoline, set on fire. What remains will be entombed in a cubic foot of cement and buried 6 feet down after which an oak tree will be planted on top of that. A sign will say : here lies the biggest crap idea ever conceived.
What are you going to repair on such things ?
The battery ? unobtainium.
The circuitboard ? good luck buying a BGA rework station, getting your hands on the custom chips and developing the fine motor skills to replace 01005 capacitors off a flex board.
While i applaud iFixit historically for doing teardowns ( not really needed , go on FCC website and look up detailed apple provided innard shots ) , the state of current hardware makes things irrepairable apart from swapping a module. That is not repairing. Repairing is component level debug like Rossman is doing.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2021
