Er, the same way USB was for years? Actually, DRI, too. The driver exposes a pseudo-device in/dev/, which actually is a socket-like, high-throughput mmap wrapper and the X server opens it. Given appropriate file permissions and group membership, this can be done from a user account.
Does this still bother you, even with today's LCDs? I'm currently sitting at the side of my desk, typing this on a laptop, and I can read the text just fine on either of the two Dell 1905FP LCDs at the center of my desk, with one about 40cm away at a 45deg angle and the other about 80cm away at a 70deg angle. Both are displaying 12pt black-on-white antialiased text (PDFs) at 90dpi.
That's for a major Polish website devoted to a popular, long-running game series. The userbase is indeed a little more tech-conscious than the average Internet user around here, but not by much - just a few power gamers and techies, lots of "casuals". Nevertheless, IE was at ~70% in 2004, ~50% in 2005 and so on down to ~25% in the late 2008 and ~20% now. Right now it's kind of stabilizing (but still falling) and I don't forsee it falling below 15% anytime soon, but I'm starting to suspect that by the end of the year, Opera might overtake it (16% and rising, mostly ex-Firefox users right now).
We're not actively doing anything anti-IE or pro-FF/Opera (well, maybe except that IE is getting all the CSS/JS bugfixes lats, but that's *because* it's so low in the stats - we can afford letting the IE support lag behind), so it's mostly an outside trend, I think.
All the statistics I'm basing this post on were generated by Google Analytics, by the way.
But it's an instant giveaway that something sleazy is going on. Every automated security auditing tool checks for that and every sysadmin worth his salary knows this "trick".
Unless the shell is modified to append commands to the history file *before* executing them (as far as I know, no shell does that out of the box), or the system is hardened (exec() logging etc.), this will take care of any history logs.
Solid 7h on a 5200mAh (70Wh) battery, while browsing, coding and doing other things I usually do when I'm on the university campus a whole day, moving from building to building (there's WiFi everywhere, but almost no freely available power outlets in the older buildings, anyway). PLD Linux, kernel 2.6.27.7, X.org 1.6.0, KDE 3.5.10.
That's interesting. Which version of Konq? On 3.5.10, the Slashdot discussion system is FUBAR for a few weeks now. It was working fine, in-place replies, dynamic comment loading and all, but it stopped at some point.
Well, at any moment I could get a piece of paper and a pencil, and design a deployment plan for my project that would use the right tool for the job on every level, hardware, software and all - but it would stay there, on paper, simply because of the initial cost.
In fact, I wouldn't agree on not following my own advice - I call it a rule of engineering, and engineering deals with real-world problems with real-world constraints. In this case, the constraint is financial, so I get to choose the right tool from what I can afford. This, unavoidably and regrettably, means that the right tool is an underpowered server combined with sufficiently optimized software - after all, it works properly. Consequently, the same underpowered server running slow software not optimized for the specific task would be an example of a bad tool for the job.
As for the skills and time required to develop them, take a look at my other reply in this thread - I'm not doing that just for fun. It turns out that the skillset required in my situation is quite similar to the one necessary at the other end of the spectrum, where the scale of a deployment is so big that off-the-shelf technology doesn't cut it and custom solutions must be carefully developed for a specific task. Even some of the specific techniques employed in the process are almost the same - especially using different databases, filesystems, programming languages etc. in unison, to get the most out of every piece.
In this case the "client" is actually me and a few friends (and the users, sort of). We're putting so much time and effort into it in part for the experience we get, and that really pays - one of us got a very good job recently, just because he learned to write efficent, maintainable code and use and combine different technologies when appropriate, rather than sticking to one thing no matter what.
Besides, the pricing on dedicated servers is all screwed up, as is the usual selection of hardware configurations. And don't even get me started on the fact that colocating our own box costs more than leasing the same - in terms of rack space, power draw and cooling - thing.
Oh, and many popular CMSes were a security nightmare until recently. Now it's mostly OK, but five years ago, when we started, most PHP frameworks and CMSes were crappy, Python-based hosting was still rare and expensive and we did not have our own server yet.
I'm not sure what exactly were you trying to say, but I'm afraid that common sense is, indeed, futile when confronted with severely limited money to spend on hosting.
I guess it's a matter of applying one of the most important rules of engineering, "use the right tool for the job", properly.
Ready-made frameworks are, to the best of my knowledge, good for small-to-somewhat-biggish-medium deployments (measuring primarily in the terms of hits per a unit of time, the amount of content being somewhat less important, unless it's really huge) with a good safety margin of available CPU time and I/O bandwidth on the server. Very big websites and small-to-medium websites operating in a severely constrained environment (like a cheap shared account, or a single, underpowered dedicated server), on the other hand, require mostly custom coding.
I don't think there's any site the size of YouTube or Facebook using some premade, general-purpose CMS (or whatever you like to call all those Drupal-like things), at least not without some heavy custom optimisations or excessive hadrware expenses (yeah, I know, Wikipedia is, technically speaking, using a premade CMS, but it was designed for a specific huge deployment in the first place).
At the same time, squeezing a popular website onto a cheap hosting platform demands custom coding, too - CMSes, with their modularity and layers upon layers of abstraction (which is surely good from the programmer's and maintainer's point of view) require quite a bit of resources for even such simple tasks as checking the user's session, permissions, profile data etc., which have to be done on every request.
Personally, I'm involved in a project of the latter category, a popular webpage operating from a cheap dedicated machine (single core, 1GB of memory, one logical disk, cheap disk controller with limited I/O bandwidth), and it's a nontrivial task to keep it running smooothly. In a few places it was necessary to do some custom coding at the HTTP server level, use different types of databases to do different things and even utilize specific filesystems for different partitions that hold data of different nature (lots of small, fast-changing files on one, some big, mostly appended to files on another, etc). The scripting itself, too, was written with performance in mind, sometimes even breaking design patterns (with due care and big fat warnings in the comments, of course). Not long ago, I measured the performance of this contraption and while there's still room for improvements (mostly around database schemas and smart caching), it was able to outperform Plone, Joomla and a few [...]-Nukes tested under a similar workload pretty easily. Sure, it *was* a lot of work to do, but still probably less than modifying an existing CMS for such a level of specialization. (Oh, and before someone asks - no, I'm not giving the URL, I'm quite proud of my code, but I'm also sure it's not *that* fast yet.)
And how do you call someone who tells you "I don't care wether there are any gods or not, because I don't have a need to believe in a deity"? Isn't this atheism, too?
That's because she was using a telescope - even a small one negates the problem. Just like observing the sky from the bottom of a well. Standing in a 10m-deep well in the middle of a bright day you will see a piece of night sky, with stars and all, when you look up (well, except when you're on the equator and it's exactly the midday, but that's a corner case of sorts).
It's still very likely that the night sky around where she lives is too polluted with light to see anything interesting with the naked eye.
No. If an engineer designs a car and it crashes due to easily-avoidable defects, his company is fined big bucks in court. If an engineer designs a program and it crashes due to easily-avoidable defects, his company tells the client "go read the EULA and fuck off, we're not responsible". So, the first engineer's company gives him the money, means and time required to avoid those defects. The first engineer's company doesn't bother, so the engineer doesn't find those defects, even if he'd like to, because he'd be fired for not meeting the deadline and wasting time on something that doesn't affect revenue.
Well, in fact, there were cases of car companies figuring out that paying a few families some change money would be cheaper than acutally fixing those easily avoidable defects, but that's another matter.
For me, it's a dumping place for whatever I want to write quickly and store online for others (not necessarily everyone) to see. I'm using dokuwiki, as it's dead simple to set up, use and maintain.
If it wasn't for my lack of free time, I'd definitely run a devblog, too - sometimes I stumble upon a good, but obscure solution for some difficult, common problem in programming, *nix administration etc., and most good, but obscure solutions I ever read about were published on devblogs. However, writing a decent blog post about such things requires quite some time and effort, so, maybe, someday I will, but not now.
You have it right there. I'm using a Soviet-made C1-99 oscilloscope from the 80s, which still works, still holds calibration settings for a few years at a time and still amazes me with its design. When I opened it for the first time, to replace a thread-secured cord socket (the cord got damaged and I wasn't able to find a new one that would fit) with a modern C14 socket, I was surprised to find a ~1,5m long coil of shower hose securely attached between the circuit boards, definitely factory work. It wasn't just some braided metal tube, it was an actual piece of shower hose, just with the ends cut off. Some googling revealed that this is a 15ns delay line, required for the synchro circuity to keep up with processing the signal at 100MHz. And this piece of shower hose is why this scope can do 100MHz reliably. Western designs of the age had instead utilized varous kinds of solid-state signal buffers and whatnot that showed problems with certain uncommon signals and were definitely much more expensive than a piece of shower hose.
Well, I've got a Marantz Superscope R-1232 amplituner manufactured in 1971, which was really at the bottom end of the Marantz product range, and AFAIK it was priced accordingly (affordable for almost everyone), yet it still works perfectly without a single repair in almost 40 years of use.
Recently, I've become a heavy user of Autodesk products, mainly Inventor and AutoCAD Mechanical - and in the 2010 version, which came out a month ago (yeah, someone must have made a prank with the wall calendar at the Autodesk offices and they didn't notice until it was too late), they switched to ribbons. So, Inventor 2010 looks just like Microsoft Office, with the big icon in the corner and so on - thus the look is there, but the feel, it's different. They dropped most of the context-driven dynamic ribbon failure and just add a new tab when applicable, but the core set of tabs stays the same in a much wider context. Moreover, the tools are actually in right places and properly grouped. Oh, and for anyone used to the old ways, there was an option to switch to the old-style interface, I think. But I didn't, after trying out the ribbons - they are really well-done and speed things up a lot.
So, the ribbons themselves are quite a good idea, if implemented properly, it's just the MS Office that doesn't use them to their full potential.
Yes, yes, that's what the books and professors at the university try to teach you.
The reality... Well, it's kind of different, you see. The client did not know what he wanted when writing down the specs, the guys writing the spec were incompetent, the testers were lazy - and finally, it's you, who followed the specs to the letter, who has to hang above a vat of chemicals with a 'scope and a laptop and tweak the code to make it actually do what the client wanted, not what he meant and the spec guys understood. Ever seen this?
Human skeleton can support much more weight than the muscles could ever lift. After all, the athletes with several times more muscle than a normal person can lift several times more than a normal person could, but their skeletons aren't several times more durable. Exercise makes them a bit stronger, due to good blood supply rich with macroelements, but the same could be achieved with just a good diet and some normal daily exercise, not necessairly athlete's training sessions.
So it will be possible to use this for some weight lifting - I guess 100kg would be easy, there was a video of a guy in a prototype of this device carrying 100kg of rice around the lab. 200kg should be manageable, maybe 300kg could be the limit for most people, as that's what some athletes can still manage safely for a while. Well, ask a doctor specialising in skeletal aliments for some hard facts, I think they'd be quite interested in figuring this out.
I'm afraid there are some real use cases where a properly calculated, truncated logarithm value is actually needed as an intermediate step in a more complex expression, so the formatting isn't going to help. And most spreadsheets handle this situation much better, feel free to read my other replies in this thread to see why and how.
I'll repeat what I said in another reply: I am aware of the floating point representation problem, but Google Docs doesn't give any clues on what the problem is and where it is, it shows two "3.00"s that trunc() to a different value, not a "2.999999..." or "2.(9)" or whatever else might be appropriate there. Basically, it claims that the value of an expression is X, but still treats it as Y, silently. While that was a simple and somewhat obvious example (I mean, for us - it's more than enough to confuse the hell out of normal people), tripping over this bug in the middle of some monster equation would be no fun, because it would be extremely hard to track this down. Other applications either alter the intermediate value so that it's correct (where the definition of being correct is determined by the working context and purpose of the calculation, not some innate characteristics of the hardware) and actually do the math using the same numbers that are shown to the user, or do no correction at all and show everything as it is stored in the memory. Doing the former in a half-arsed way and coming up with results calculated as if the latter was done is a bug.
Slashdot Mirror
Er, the same way USB was for years? Actually, DRI, too. The driver exposes a pseudo-device in /dev/, which actually is a socket-like, high-throughput mmap wrapper and the X server opens it. Given appropriate file permissions and group membership, this can be done from a user account.
Does this still bother you, even with today's LCDs? I'm currently sitting at the side of my desk, typing this on a laptop, and I can read the text just fine on either of the two Dell 1905FP LCDs at the center of my desk, with one about 40cm away at a 45deg angle and the other about 80cm away at a 70deg angle. Both are displaying 12pt black-on-white antialiased text (PDFs) at 90dpi.
That's for a major Polish website devoted to a popular, long-running game series. The userbase is indeed a little more tech-conscious than the average Internet user around here, but not by much - just a few power gamers and techies, lots of "casuals". Nevertheless, IE was at ~70% in 2004, ~50% in 2005 and so on down to ~25% in the late 2008 and ~20% now. Right now it's kind of stabilizing (but still falling) and I don't forsee it falling below 15% anytime soon, but I'm starting to suspect that by the end of the year, Opera might overtake it (16% and rising, mostly ex-Firefox users right now).
We're not actively doing anything anti-IE or pro-FF/Opera (well, maybe except that IE is getting all the CSS/JS bugfixes lats, but that's *because* it's so low in the stats - we can afford letting the IE support lag behind), so it's mostly an outside trend, I think.
All the statistics I'm basing this post on were generated by Google Analytics, by the way.
But it's an instant giveaway that something sleazy is going on. Every automated security auditing tool checks for that and every sysadmin worth his salary knows this "trick".
$ sftp && kill -9 `/sbin/pidof `/bin/basename $SHELL``
Unless the shell is modified to append commands to the history file *before* executing them (as far as I know, no shell does that out of the box), or the system is hardened (exec() logging etc.), this will take care of any history logs.
That's right. It's modifying the in-memory binary image (that is, the machine code), while it's actively up and running.
Solid 7h on a 5200mAh (70Wh) battery, while browsing, coding and doing other things I usually do when I'm on the university campus a whole day, moving from building to building (there's WiFi everywhere, but almost no freely available power outlets in the older buildings, anyway). PLD Linux, kernel 2.6.27.7, X.org 1.6.0, KDE 3.5.10.
Oh, well. They must've fixed something important in 4.x. Well, good to know. Even though I'm not switching to KDE4, still no OS X xtyle menus there...
That's interesting. Which version of Konq? On 3.5.10, the Slashdot discussion system is FUBAR for a few weeks now. It was working fine, in-place replies, dynamic comment loading and all, but it stopped at some point.
Well, at any moment I could get a piece of paper and a pencil, and design a deployment plan for my project that would use the right tool for the job on every level, hardware, software and all - but it would stay there, on paper, simply because of the initial cost.
In fact, I wouldn't agree on not following my own advice - I call it a rule of engineering, and engineering deals with real-world problems with real-world constraints. In this case, the constraint is financial, so I get to choose the right tool from what I can afford. This, unavoidably and regrettably, means that the right tool is an underpowered server combined with sufficiently optimized software - after all, it works properly. Consequently, the same underpowered server running slow software not optimized for the specific task would be an example of a bad tool for the job.
As for the skills and time required to develop them, take a look at my other reply in this thread - I'm not doing that just for fun. It turns out that the skillset required in my situation is quite similar to the one necessary at the other end of the spectrum, where the scale of a deployment is so big that off-the-shelf technology doesn't cut it and custom solutions must be carefully developed for a specific task. Even some of the specific techniques employed in the process are almost the same - especially using different databases, filesystems, programming languages etc. in unison, to get the most out of every piece.
In this case the "client" is actually me and a few friends (and the users, sort of). We're putting so much time and effort into it in part for the experience we get, and that really pays - one of us got a very good job recently, just because he learned to write efficent, maintainable code and use and combine different technologies when appropriate, rather than sticking to one thing no matter what.
Besides, the pricing on dedicated servers is all screwed up, as is the usual selection of hardware configurations. And don't even get me started on the fact that colocating our own box costs more than leasing the same - in terms of rack space, power draw and cooling - thing.
Oh, and many popular CMSes were a security nightmare until recently. Now it's mostly OK, but five years ago, when we started, most PHP frameworks and CMSes were crappy, Python-based hosting was still rare and expensive and we did not have our own server yet.
I'm not sure what exactly were you trying to say, but I'm afraid that common sense is, indeed, futile when confronted with severely limited money to spend on hosting.
I guess it's a matter of applying one of the most important rules of engineering, "use the right tool for the job", properly.
Ready-made frameworks are, to the best of my knowledge, good for small-to-somewhat-biggish-medium deployments (measuring primarily in the terms of hits per a unit of time, the amount of content being somewhat less important, unless it's really huge) with a good safety margin of available CPU time and I/O bandwidth on the server. Very big websites and small-to-medium websites operating in a severely constrained environment (like a cheap shared account, or a single, underpowered dedicated server), on the other hand, require mostly custom coding.
I don't think there's any site the size of YouTube or Facebook using some premade, general-purpose CMS (or whatever you like to call all those Drupal-like things), at least not without some heavy custom optimisations or excessive hadrware expenses (yeah, I know, Wikipedia is, technically speaking, using a premade CMS, but it was designed for a specific huge deployment in the first place).
At the same time, squeezing a popular website onto a cheap hosting platform demands custom coding, too - CMSes, with their modularity and layers upon layers of abstraction (which is surely good from the programmer's and maintainer's point of view) require quite a bit of resources for even such simple tasks as checking the user's session, permissions, profile data etc., which have to be done on every request.
Personally, I'm involved in a project of the latter category, a popular webpage operating from a cheap dedicated machine (single core, 1GB of memory, one logical disk, cheap disk controller with limited I/O bandwidth), and it's a nontrivial task to keep it running smooothly. In a few places it was necessary to do some custom coding at the HTTP server level, use different types of databases to do different things and even utilize specific filesystems for different partitions that hold data of different nature (lots of small, fast-changing files on one, some big, mostly appended to files on another, etc). The scripting itself, too, was written with performance in mind, sometimes even breaking design patterns (with due care and big fat warnings in the comments, of course). Not long ago, I measured the performance of this contraption and while there's still room for improvements (mostly around database schemas and smart caching), it was able to outperform Plone, Joomla and a few [...]-Nukes tested under a similar workload pretty easily. Sure, it *was* a lot of work to do, but still probably less than modifying an existing CMS for such a level of specialization. (Oh, and before someone asks - no, I'm not giving the URL, I'm quite proud of my code, but I'm also sure it's not *that* fast yet.)
And how do you call someone who tells you "I don't care wether there are any gods or not, because I don't have a need to believe in a deity"? Isn't this atheism, too?
That's because she was using a telescope - even a small one negates the problem. Just like observing the sky from the bottom of a well. Standing in a 10m-deep well in the middle of a bright day you will see a piece of night sky, with stars and all, when you look up (well, except when you're on the equator and it's exactly the midday, but that's a corner case of sorts).
It's still very likely that the night sky around where she lives is too polluted with light to see anything interesting with the naked eye.
No. If an engineer designs a car and it crashes due to easily-avoidable defects, his company is fined big bucks in court. If an engineer designs a program and it crashes due to easily-avoidable defects, his company tells the client "go read the EULA and fuck off, we're not responsible". So, the first engineer's company gives him the money, means and time required to avoid those defects. The first engineer's company doesn't bother, so the engineer doesn't find those defects, even if he'd like to, because he'd be fired for not meeting the deadline and wasting time on something that doesn't affect revenue.
Well, in fact, there were cases of car companies figuring out that paying a few families some change money would be cheaper than acutally fixing those easily avoidable defects, but that's another matter.
For me, it's a dumping place for whatever I want to write quickly and store online for others (not necessarily everyone) to see. I'm using dokuwiki, as it's dead simple to set up, use and maintain.
If it wasn't for my lack of free time, I'd definitely run a devblog, too - sometimes I stumble upon a good, but obscure solution for some difficult, common problem in programming, *nix administration etc., and most good, but obscure solutions I ever read about were published on devblogs. However, writing a decent blog post about such things requires quite some time and effort, so, maybe, someday I will, but not now.
You have it right there. I'm using a Soviet-made C1-99 oscilloscope from the 80s, which still works, still holds calibration settings for a few years at a time and still amazes me with its design. When I opened it for the first time, to replace a thread-secured cord socket (the cord got damaged and I wasn't able to find a new one that would fit) with a modern C14 socket, I was surprised to find a ~1,5m long coil of shower hose securely attached between the circuit boards, definitely factory work. It wasn't just some braided metal tube, it was an actual piece of shower hose, just with the ends cut off. Some googling revealed that this is a 15ns delay line, required for the synchro circuity to keep up with processing the signal at 100MHz. And this piece of shower hose is why this scope can do 100MHz reliably. Western designs of the age had instead utilized varous kinds of solid-state signal buffers and whatnot that showed problems with certain uncommon signals and were definitely much more expensive than a piece of shower hose.
Well, I've got a Marantz Superscope R-1232 amplituner manufactured in 1971, which was really at the bottom end of the Marantz product range, and AFAIK it was priced accordingly (affordable for almost everyone), yet it still works perfectly without a single repair in almost 40 years of use.
Recently, I've become a heavy user of Autodesk products, mainly Inventor and AutoCAD Mechanical - and in the 2010 version, which came out a month ago (yeah, someone must have made a prank with the wall calendar at the Autodesk offices and they didn't notice until it was too late), they switched to ribbons. So, Inventor 2010 looks just like Microsoft Office, with the big icon in the corner and so on - thus the look is there, but the feel, it's different. They dropped most of the context-driven dynamic ribbon failure and just add a new tab when applicable, but the core set of tabs stays the same in a much wider context. Moreover, the tools are actually in right places and properly grouped. Oh, and for anyone used to the old ways, there was an option to switch to the old-style interface, I think. But I didn't, after trying out the ribbons - they are really well-done and speed things up a lot.
So, the ribbons themselves are quite a good idea, if implemented properly, it's just the MS Office that doesn't use them to their full potential.
...or did anyone else think "we are Linux, resistance is futile, you will be assimilated" the moment they saw the headline?
Yes, yes, that's what the books and professors at the university try to teach you.
The reality... Well, it's kind of different, you see. The client did not know what he wanted when writing down the specs, the guys writing the spec were incompetent, the testers were lazy - and finally, it's you, who followed the specs to the letter, who has to hang above a vat of chemicals with a 'scope and a laptop and tweak the code to make it actually do what the client wanted, not what he meant and the spec guys understood. Ever seen this?
Actually, it is, to some extent.
Human skeleton can support much more weight than the muscles could ever lift. After all, the athletes with several times more muscle than a normal person can lift several times more than a normal person could, but their skeletons aren't several times more durable. Exercise makes them a bit stronger, due to good blood supply rich with macroelements, but the same could be achieved with just a good diet and some normal daily exercise, not necessairly athlete's training sessions.
So it will be possible to use this for some weight lifting - I guess 100kg would be easy, there was a video of a guy in a prototype of this device carrying 100kg of rice around the lab. 200kg should be manageable, maybe 300kg could be the limit for most people, as that's what some athletes can still manage safely for a while. Well, ask a doctor specialising in skeletal aliments for some hard facts, I think they'd be quite interested in figuring this out.
I'm afraid there are some real use cases where a properly calculated, truncated logarithm value is actually needed as an intermediate step in a more complex expression, so the formatting isn't going to help. And most spreadsheets handle this situation much better, feel free to read my other replies in this thread to see why and how.
I'll repeat what I said in another reply: I am aware of the floating point representation problem, but Google Docs doesn't give any clues on what the problem is and where it is, it shows two "3.00"s that trunc() to a different value, not a "2.999999..." or "2.(9)" or whatever else might be appropriate there. Basically, it claims that the value of an expression is X, but still treats it as Y, silently. While that was a simple and somewhat obvious example (I mean, for us - it's more than enough to confuse the hell out of normal people), tripping over this bug in the middle of some monster equation would be no fun, because it would be extremely hard to track this down. Other applications either alter the intermediate value so that it's correct (where the definition of being correct is determined by the working context and purpose of the calculation, not some innate characteristics of the hardware) and actually do the math using the same numbers that are shown to the user, or do no correction at all and show everything as it is stored in the memory. Doing the former in a half-arsed way and coming up with results calculated as if the latter was done is a bug.