how did they get that?
By using an embedded system with no filesystem whose "millisecond" timer actually runs at 990Hz?
how did they get that?
By using an embedded system with no filesystem whose "millisecond" timer actually runs at 990Hz?
@FrostCat said in Team of developers need new monitors (need advice):
@asdf said in Team of developers need new monitors (need advice):
I have the 23'' variant (U2312HM).
Are these things better than the normal run-of-the-mill Dells? Because the ones we have at work suck.
Dell uses three kinds of panels at three different price points. The rock bottom line beloved by bean counters uses TN panels, which suck donkey balls. The mid-price Ultrasharp range, which includes the now-superseded U2412M, uses IPS panels which are really nice to work with in normal office lighting but have noticeable backlight bleed when viewed in the dark. Higher-price Ultrasharp models use better IPS panels that look good in the dark as well.
Dell is one of the few manufacturers offering high-performance panels with an anti-glare coating, too; most of the others have a high-gloss finish, which looks tremendous given careful ambient lighting design but suffers badly without it.
1. n=0
2. Generate file from current time + n.
3. Check if file exists.
True: save file.
False: n++ and goto 2.What's so hard about it?
Y U NO USE THE FILENAMES THEMSELVES
It's an O(n) algorithm, where n is the number of files generated too soon to get naive timestamp names, and under conditions unanticipated by Marketing (i.e. somewhere, sometime in the real world) it can end up doing a lot of unnecessary work. Remembering a single value sufficient to generate the next filename without search, as proposed by both Jaime and myself, is O(1).
If you get big surge of activity then the whole algorithm is flawed because it works only for n small enough for users to not notice that reports get future timestamps.
The whole specification is flawed from the start, as is clearly apparent to everybody except the sales droids. As a working coder, my response to idiotic specifications I can't persuade the client to disidioticate has always been to try to implement them in ways that make their unavoidable edge case failures as unsurprising and unproblematic as possible.
>Jaime:
2.Attempt to create file from current time + n, with "don't overwrite existing" flag on.That's implementation detail of checking for file existence. Please don't expose implementation details to API level if it doesn't give you significant performance gains.
when it starts taking 1 minute to find the next available file name, then you can't generate more than 1 per minute, problem solved.
Isn't @Weng's org the one that spends six figures per terabyte on disk storage? I'm sure they could just add another server farm to generate filenames. Think of the XML deployment opportunities!
That particular information model should certainly not be common.
No, no, no, no, no. The thing on the desk that shows pictures of cats is the user's Windows.
Surely that's their Microsoft?
I think you need to read Frederick P. Brooks' essay No Silver Bullet again. It's just as true today as it was when it was written.
The Mythical Man-Month has aged very well also.
Maybe have a dashboard for managers.
Release the resulting code as a library with a hard dependency on a huge tree of other libraries for rendering 3D pie charts.
Surely it would be simple for a compiler to re-arrange your code to do that for you at compile-time so I don't have to have temp variables clogging up the start of a function.
You did know that C variables are scoped by block, not function? There's nothing but an arbitrary style guide stopping you from writing code like
if (a > b) {
int temp = a;
a = b;
b = temp;
}
and being able to be confident that temp
hasn't stomped anything else. Variable scope also extends from point of declaration to the end of the innermost block containing the declaration, so again there is nothing but a style guide stopping you from putting code that doesn't use a given variable before its declaration.
thanks to Arch and Debian
I've never played with Arch. I stayed with Red Hat until 9, then switched to Ubuntu Breezy; used Gnome on Ubuntu until the bugfuck insanity revealed itself with Lucid, at which point I jumped ship to Debian Testing; on being completely blindsided by the unexpected arrival of Gnome 3 after a careless aptitude full-upgrade
I experimented briefly with Mate before settling on Xfce with Debian Testing, which I'm still quite happy with. I also run a handful of headless Debian Testing servers.
Does Arch offer anything compelling enough to make a satisfied Debian Testing user consider switching?
where it took a full week to count votes in elections
Which goes to show they're using paper, which despite this fiasco I still rate as way, way less susceptible to tampering than anything more automated.
I was a happy little Australian with my chip-and-PIN card... and then all the banks started issuing all this NFC bullshit, where just putting the card near the reader for two seconds is enough to authorize any transaction of up to $100. Didn't ask for that. Didn't want that. No way to turn it off either, without risking destruction to the chip.
The slot in my wallet where my EFT card lives now has a copper foil lining, with little bumps positioned to press onto all the chip contact pads and short them all together. With any luck that's enough to discourage most remote readers.
if I ever review a line like that, it will be rejected with extreme prejudice
++++++++++a would reject again
when are we going to have people advertise weird made-up names for btrfs parity volumes?
I have never really understood this attachment to dd, especially since so many people fail to add the bs=1M argument to make it run at a reasonable speed. A simple cp /path/of/iso/image /path/of/usb/drive
is way faster than dd without bs=1M, doesn't need the weird-ass if= and of= prefixes that mess up tab completion, and doesn't crap up your terminal afterwards with useless cruft about the number of blocks transferred.
cat /path/of/iso/image >/path/of/usb/drive
works fine too, which means that if you've got a large ISO image stored in pieces on e.g. FAT32 media, you can write it out to the USB stick with cat /path/of/iso/image-part* >/path/of/usb/drive
.
You don't have to use the friendly names.
Exactly!
In these tough economic times it's every citizen's duty to promote maximum consumption.
Windows 98SE can be made to run very nicely in VirtualBox (on either a 32 or 64 bit host OS) and that's what I'll generally use to make a compatible environment for elderly software. I am not aware of any 3.x era stuff that won't run on 98SE.
You don't get hardware GPU support because VirtualBox doesn't have guest drivers available for 98SE, but today's CPUs are generally fast enough compared to 98SE-era GPUs that it doesn't matter much. Microsoft's own virtualization stuff might support Win98 better; I've not played with it so I don't know.