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

Even Archive.org is rather limited in what it keeps. I know of a very large site that recently disappeared. archive only has part of the web html part of the site. Everything else is either gone or non accessible.


That's not my experience


Most of the time it isnt mine either. But here and there there will be large swaths of some site that are just not archived. At one point if someone put up a robots text file history would just vanish. Have not checked lately if that still holds. But one company I worked for was just 'gone'. Because a webpage squatter put up a robots.txt.


There needs to be some kind of "murphy's law" for this style of comment. "For any comment on the internet where someone points out an issue they've encountered with technology, there will inevitably be a reply from someone else sharing that they haven't personally experienced it."


I think you get to coin it.


s'-0_0-'s law


There are. Several model maker communities use it to put stuff up for sale. It is a nice way to find other model makers.

The reason I joined FB no longer exists for me. I remember why I stopped talking to many of the 'friends' I had. I silenced all of them and only join interesting groups now. Even then I only log in once or twice a year.


'always online' has created a whole new set of buggy from a lot of companies. For example cyberpunk is NOW a playable game. Launch date was a very mixed bag. 'fix it after launch' ugh.


> cyberpunk is NOW a playable game

I never had problems with cyberpunk but I think I know why: I built a new PC right around its release and it was good enough to play it smoothly on 4K medium or HD ultra.

When I checked to see what 4K ultra looked like, the graphics latency caused a bunch of scripting to fall apart and the game glitched really bad.

IIRC the console release was notorious for bugs, so I assume consoles were not performant enough to run the game buttery smooth nor could they be easily upgraded.


I encountered bugs when it first released even with a decent PC. IIRC there was a mission where you were running away in a truck, and it would crash every time at a certain point so I could never complete it. Also the whole save file size limit debacle, where they never actually removed deleted items from your inventory and the save file would reach a certain size that the game could no longer read (10mb or something like that)


I've played through the whole thing on the day one patch. On PC it was really not that bad. On console was another story though


> When I checked to see what 4K ultra looked like, the graphics latency caused a bunch of scripting to fall apart and the game glitched really bad.

That is ... interesting. The game use wall clock waits or something instead of "game logic tic" wait?


Cyberpunk was a dumpster fire on release, I'm not joking, you could have two machines seemingly identical but get wildly different performance, it was an absolute mess.

Even to this day after so many patches some bugs still are present.

The PS4 release was notoriously bad because they were reliant on caching from disk, if it's an SSD it's ok, if it's a hard drive, though luck...

This is even worse when you look at all the marketing material leading up to release, if you put that together it's close to fraud in my opinion...


Having just put a battery into my existing system. For the power company I use the answer is no to your question. Many power companies charge that fee depending on the size of panels. Now if you do not hook to their system they do not care (off grid). But if you plug into it then they care and charge for the privilege.

Now you could pull particular items out of their grid. Just need the wires and panels to make sense. They would not care about that either. It is only if the panels are plugged into the grid they start to care. Downside is sometimes waiting for that battery to have enough juice to work. It goes faster than you think and some battery systems are decently expensive just by themselves, on top of the panels/inverters/controllers/install.


In that kind of situation you could work around this legally just by reconnecting loads to the other system as needed. E.g. battery is getting low, better unplug the fridge from the green-painted solar power outlet and plug it into the red-painted grid power outlet right next to it. You maintain the air-gap but still get to load-balance.


I did something similar in win16/32 at one point. Think we wanted something special with graphics on the button.

We basically had to recreate all of the actions of focus/unfocus/etc. Everything a normal button could do. Now that I have done more stuff I a know for a fact I made my life way harder than it should have been and could have subclassed. But it was a full button recreation. Styling messaging and all. You have to watch for things like what if someone clicks outside of your button but lets go inside the button. What does that mean? All sorts of weird side effects. What if your button has focus and someone starts typing? What if someone clicks outside of your button but holds the button down as they slide across your button? What does that look like?

Would I ever do it again. Probably not. Seriously use the built in ones.


and sometimes you can not do that. if it is some sort of historical thing.


or filled with asbestos.


Probably talking about swapping it in from some external datastore. These days you would open the file and dump it into a single buffer and rip across it, and not even really stress about it. Even 256 meg of hard drive. That would have been impressively expensive in the 80s.

Back then you had to chunk it out and fiddle with the offsets. Even then you still would have had to manage loading out the next chunk.

If my memory is right 1MB of memory in the early 90s was like 200-300 per meg. Would have to dig up a computer shopper and look.


> Even 256 meg of hard drive. That would have been impressively expensive in the 80s.

I only have a couple reference points around this scale:

My dad's company had a system set up with a searchable index of a bunch of legal testimony. It was a Compaq Deskpro 386 running Unix with an attached 1GB disk. The 1GB disk set up was as big as the machine itself.

A few years later, I worked with a Cyber mainframe equipped with around 30GB of total attached disk storage. The disk array literally filled a room.

256MB disk on an 80's PC would have definitely been quite a bit.


I remember my dad bought a 500MB hard drive for our Apple IIgs. It cost like $500-600 as I recall, not cheap by any means. I remember thinking that no way would we ever fill it up - which, to be fair, we never did. 500MB would fill up instantly now, but programs and data were so much smaller back then that it lasted until the computer eventually stopped being used.


Also you need to be careful what you read/write. In some cases.

As many examples out there use int/char etc to show how to use the thing. But if you switch to structs that fwrite can totally burn you if you use the sizeof call. As the sizeof a struct can vary between platforms and compilers. Depending on packing. Then endianness can sometimes mess you up. If you are reading/writing for yourself you can get away with a lot. But if you are trying to interop then you have to be wildly careful what you do.

fwrite is another one where people will do one byte at a time (same up to for the windows version). Bash out a loop, use the sizeof for the input to the for loop. copy and paste just doing 1 byte and you can easily end up here. One program I added a cache in front of the thing so it would always write on disk block boundaries and then come back for more. I started off with just packed struct sizes but the perf was just 'ok'. The file block boundary thing really made it fast. Not all OS's have a readahead/write buffer behind that call so perf can vary.

It is honestly such an easy mistake to make. As many of the examples/docs do not really show you why/how to use both of those calls in the way needed. You sort of have to stumble into it and work it out.

Once you see it you know. But until then you do not really notice if it is 'working'.


Are you sure you're not thinking of raw read() / write() (the operating systems calls) rather than fread() and fwrite() (the C standard library functions)? fread and fwrite already have a cache, so repeated calls won't make lots of OS calls.

Or, at least, they shouldn't! Clearly OP's implementation was a counterexample (it made lots of OS calls just for a single fread call).


Unfortunately not all of them. It depends on the device you are using, and the storage device, and the kernel, and the CRT you are using. The process I was using went from like 20-30 seconds to run to less than a second once I put a cache in front of it. Current implementations may have that cache. I would look first and see what they are doing. At the time I was working with about 6 different CRT's of varying age and quality. Some systems you can turn it on and off per device, or global, or per call depending on flags passed in. Really it comes down to reading the docs (probably right), and testing it out (empirical evnidence). That project I learned to not trust the c runtime libraries. But to verify what they are doing and re-read the docs and make sure I am even using the thing correctly vs what is written in the code and my assumptions.


There is one game called 'hack n slash' on steam. You manipulate the 'global vars' to win the game. There is even one point where the game has you open up its data files and change things. Interesting mechanic.


On some systems/drives if it detects an error that is big enough it will reset the carriage. You can here it reading and rescrubbing over and over. That can cause the carriage motor to overwork and burn out. Not sure of this system does that or not. But that would be my guess.


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

Search: