1) Most home users run BeOS and so are forced to program in Python and Ruby instead of C# and Java during the weekends. 2) Python and Ruby are only used by children. On the weekdays, those children have homework to do and so ask fewer questions. 3) Home users don't own Visual Studio and so program in Python and Ruby instead of C# on the weekends. Users that would be programming in Java are too busy trying to get Eclipse working. 4) Python and Ruby are harder to use so during the weekends when people are working on their own projects, they ask more questions. 5) No one writes code in Perl. Ever.
If I were to have the ability and/or inclination to design a system of encryption designed to not arouse suspicion it would have to be something that is there by default like having a separate partition or container file for each user with the encryption tied-in to their user account so when logging in their login credentials are the encryption key and the volume is auto mounted transparently. Maintaining a separate file or partition for each user would assure privacy both within the system and upon any kind of post-mortem analysis (such as a forensic analysis using EnCase, FTK or TSK). These are just my musings and as the author of the article said getting any kind of wide support for such a technology is unlikely and will probably never happen. It's interesting to muse on it however!
You can already do this with linux, encfs and PAM. There is a PAM authentication module that allows you to automount an encfs home directory (or any directory for that matter) and require both a login password and encfs password. If they are the same you only need to enter a single password and it's used for both authentications. If they are different, or you are using ssh keys to access the server, you still need to enter the password for the encrypted filesystem. It can also be setup so that upon logout, the encfs volume is unmounted.
The only caveat to this approach is that when the user is online, you can su to that user and see their decrypted documents (without the su, even as root, you get a permission denied by even trying to look at the encrypted directory). However, I would think it would give you a certain amount of plausible deniability in that you can freely acknowledge that there encrypted volumes on your machine and that you literally have no way to unencrypt them. Of course, they still may attempt to track down the users and get the keys (which would be interesting if you created dummy accounts and only accessed them via Tor) or, more likely, just charge you with aiding and abetting criminals.
Actually, if you decompile the DSDT of many machines you will see that they do indeed detect what OS is running and act accordingly. This is the cause of a lot Linux problems because BIOS vendors will special case something for, say, XP that isn't needed in Vista but is needed in Linux. As the machine has been identified as running Linux and not XP, that special code isn't run. The Linux kernel even has boot options to allow you to identify to the BIOS that you are running a different OS for this very reason.
Rather than just zoning out and trying not to fall asleep, create yourself a list of problems that you can think about and take notes on your thoughts during the meeting. Not only does it look like you are diligently writing down pertinent meeting information but, you don't break your concentration flow.
The one pre-requisite for this is that you have to have someone in the meeting who actually *does* take notes and is responsible for the minutes. If you are asked to write up the minutes after the meeting, your boss is not going to be pleased when they read:
You are still incorrect. Applications can do some "windowing magic" to make it appear as though they are addressing more than 32-bits seamlessly. They do not however have the ability to use 36-bit pointers. So, they aren't using PAE, they are using tricks to make it possible to use more memory than you can address while the 36-bit kernel is still handing the process 32-bit addresses.
My memory is a little foggy lately, since I've been hanging around in userland a bit, but I'm fairly certain that using long-mode (64-bit) on modern Intel CPU's for your OS and application would yield plenty of virtual address space, using PAE. Additionally, PAE supports a lot more than 36 bits of addressing on the most recent processors, up to 51 I think. The bigger question, is it practical for one CPU to use all that memory?
I think you may be confusing 32-bit with PAE and 64-bit. 32-bit with PAE is userland 32-bit with the kernel able to address 36-bit (64GB). 64-bit addresses 64-bit (16EB if I remember right) in the kernel and userland but, the CPU itself probably can't address all 64-bits so you are confined to some insanely huge addresses space that you can't fill but, it's less than 64 bits.
He's not talking about a cluster. A render farm is just a bunch of machines that can be given work to do. There is no fancy network topology so the machines can talk to each other and they aren't even expected to know of each others existence. A render farm is more akin to something like SETI@home whereas a cluster is a trying to emulate a Big Iron box. Big difference.
So if your shitting rendering app is 32 bit, not PAE aware, single threaded and you have more than 1 core than you can just pile on more processes with any modern OS and exceed 4G of usage. With a real rendering app, i.e. multithreaded, PAE aware and still 32 bit, its a no brainer.
I understand where you are going and agree with you but, applications cannot be PAE aware. It's only the kernel that deals with the 36-bit addressing. It still doles out memory as 32-bit to userland. Also, a multithreaded application wouldn't take advantage of more than 4G of memory unless the OS treats threads as separate processes because each thread is still living within a single process and that process is still bound by 32-bits of addressable memory.
A total of 10 copies of XP (for 10 nodes) may sound like a big expense, but it actually adds $140 per unit, pushing the cost of these machines to about $485 per unit for a dual-core node or $610 per unit for a quad-core configuration.
I think Tom should have rephrased that to put it into perspective: "Don't worry only 20% of the node cost is from Windows". I find it amazing that the most expensive component on the cheaper node is Windows XP and on the beefier node, it's nearly the same price as the CPU. It's even more baffling that this statement appears on the same page in reference to CPU selection:
It's really all about how much you want to spend here, because this is the single most expensive component required for each node.
Maybe Tom is a secret Linux fan and is hinting that Windows isn't a component but a tax. Or maybe he's just really bad at math.
[knock, knock] - Are you the owner of the SSID linksys - Yes... [knock, knock] - Are you the owner of the SSID linksys - Yes... [knock, knock] - Are you the owner of the SSID linksys - Yes...
Repeat several thousands times. Then replace linksys with dlink and repeat again.
Many governments publish gigabytes of CSV files, PDF files, and database files. I assume that's what you're referring to when you say you just want facts published. Should the New York Times just be filled with tables of data?
No, they should describe the contents of those documents in English and in an unbiased manner. That's what "the news" is. It's not sensationalist crap with a slant on the writers/editors/publishers view.
If you want that information translated into written English, the author of that text is going to have a point of view and a context within which they write. It's the way language works. And everyone wants other people to share their understanding of events.
Then they shouldn't be writing it. It has nothing to do with the language. What you are describing is a blog. The news is not a blog. If I read a news article that says, "this reporter thinks", "our analyst thinks", "our correspondent thinks", and I gave a fuck about what any of those people think, I would subscribe to their *blog*.
This actually made me do a double take. Why doesn't the RIAA/MPAA just create/requisition a botnet and cause the infected machines to start sharing ludicrous amounts of files. They could sue millions of people.
The problem is that this will create something that aims to be "the best". It doesn't address the problem of "what I want", it addresses the [non-]problem of "what everyone wants" and so you will still end up with homogeneous sets of things to acquire at the end of the day. Real customization of content should be player generated and not based on a system of pre-teens trying to find the most amusement in how easily they can wtfpwn some other pre-teen.
I'm not sure why suspend/resume times would be slowed with 4G of RAM and an encrypted disk. Now, hibernate/thaw times might be slowed but, suspend/resume is basically just turning off the computer except giving some power to the RAM. Although I'm not running with an encrypted disk, I have 4G of RAM in my laptop and it resumes in about 5-10 seconds and has the added benefit of keeping the disk cache in tact (which both shutdown and hibernate do not do). Although, I have no idea how long it takes to suspend. I just shut the lid and and walk away.
On a side note: I can't wait until a new OS finally achieves the startup times of the good old trusy Commodore 64.:-)
I've never understood the fascination with startup times when suspend/resume is such a more useful alternative. However, Moblin does indeed boot in 5 seconds (even in a VM) and, I will admit, it's actually pretty cool to see it.
'The standard argument is that it just boils down to "knowing how to move" or "knowing when to hit your buttons."'
That sounds like the very definition of skill to me.
The real metric is adaptation. I remember being a rogue in WoW back in the day and evasion tanking MC bosses. Not because that was part of the game plan but because the tank would die and the raid needed to adapt to the situation. When the tank got back up and was healed, I'd vanish and let him start tanking again. Raids are saved by peoples ability to adapt to the situation as it unfolds. It doesn't matter how fast you can click your buttons if you don't understand the situation you are in and how you should act during that situation. Although, I suppose you could actually qualify that as skill.
Seeing how it was done old-school is always refreshing. No C++, Java, C#, just hardcore assembly.
As an anecdote, I have a friend who used to work at MECC and worked on games for the Apple II like Oregon Trail and Odell Lake (find yourself a Way-Back Machine if you aren't familiar with those games). If memory serves me right, before leaving MECC, he wrote something akin to the following in one of those two programs:
[code] ; Important. Do NOT remove this. -- username nop nop nop ; Proceed [/code]
Years later it was apparently still in the code and he'd met up with an old colleague who asked, "What was up with the three nops? We didn't remove them because we didn't know what would happen". The response being, "Nothing, I just thought it would be funny to have this conversation a few years later".
Actually, if the application is purely CPU bound and well tuned for CPU X, then switching to the superior CPU Y may not give you an performance benefits at all until it's recompiled and possibly tuned for CPU Y. That assumes the compilers have been updated to understand how to optimally schedule instructions for CPU Y, what new instructions may be available on CPU Y, etc. Hardware vendors know these things whereas hardware consumers think that CPU Y is supposed to be faster and so their software should be running faster.
An example of this was when Sun was switching from UltraSPARC II to UltraSPARC III. Even though the UltraSPARC III chips were clocked 50% higher and had all sorts of goodies that made it seem like a better chip, when the first internal machines appeared performance was dismal and was often below UltraSPARC II in benchmarks. Once the compilers became smart enough to emit optimized code for the UltraSPARC III and once the systems engineers doing benchmarking understood the quirks of the new CPU, performance started to get more inline with expectations.
An easy way to get motivated for writing code is to write code you don't absolutely need to write but, enjoy writing. Do programming challenges, find some part of your OS that has never worked just how you wanted it to and change it, help people on programming forums, etc. When I get stuck on a bug, I find that most of the time, just a 10 minute cigarette break helps me find the answer or at least revitalizes me. For bigger Developer Blocks, doing something completely unrelated but still coding has been very useful to me in the past.
That level of polish is critical for user acceptance. If you give a user an unthemed GTK desktop (which is hideous) they will blame any and all failings in their ability to use the software correctly on it being "primitive" just because it doesn't look flashy. For better or worse, compiz wobbly windows probably drove more users to linux than, say, the superior workflow paradigm of multiple workspaces.
Having said that, I agree that workflow design is also important. It was included in the e-mails I'm referring to but, to make my point about the culture clash between Humans and Nerds, I only included the most ludicrous examples of the types of things that proper HIE will make you do.
Just out of curiosity did you notice that the product was lacking some polish before you made the changes?
No, the product seemed pleasant looking and very usable from my standpoint. After implementing the changes HIE suggested I was blown away at how great the shipping product was. In fact, that single experience probably changed the way I write GUI applications and, 10 years later, I think if I were to write a GUI application for the same company, HIE would be sending me far fewer e-mails about mundane details.
"Human Interface Engineer" sounds like a bullshit title but, if you get one that actually knows what they are talking about and you listen to them, it can drastically improve the quality of your software. I think the point of the GP was that open source software often doesn't have the level of strictness where a non-programmer can say, "No, it's not polished enough to ship". When you know that the final judge of whether your software will ship or not comes from someone that cares more about presentation/interface/usability than the technology behind it, you write your software differently.
Slashdot Mirror
It does however show the following things:
1) Most home users run BeOS and so are forced to program in Python and Ruby instead of C# and Java during the weekends.
2) Python and Ruby are only used by children. On the weekdays, those children have homework to do and so ask fewer questions.
3) Home users don't own Visual Studio and so program in Python and Ruby instead of C# on the weekends. Users that would be programming in Java are too busy trying to get Eclipse working.
4) Python and Ruby are harder to use so during the weekends when people are working on their own projects, they ask more questions.
5) No one writes code in Perl. Ever.
If I were to have the ability and/or inclination to design a system of encryption designed to not arouse suspicion it would have to be something that is there by default like having a separate partition or container file for each user with the encryption tied-in to their user account so when logging in their login credentials are the encryption key and the volume is auto mounted transparently. Maintaining a separate file or partition for each user would assure privacy both within the system and upon any kind of post-mortem analysis (such as a forensic analysis using EnCase, FTK or TSK). These are just my musings and as the author of the article said getting any kind of wide support for such a technology is unlikely and will probably never happen. It's interesting to muse on it however!
You can already do this with linux, encfs and PAM. There is a PAM authentication module that allows you to automount an encfs home directory (or any directory for that matter) and require both a login password and encfs password. If they are the same you only need to enter a single password and it's used for both authentications. If they are different, or you are using ssh keys to access the server, you still need to enter the password for the encrypted filesystem. It can also be setup so that upon logout, the encfs volume is unmounted.
The only caveat to this approach is that when the user is online, you can su to that user and see their decrypted documents (without the su, even as root, you get a permission denied by even trying to look at the encrypted directory). However, I would think it would give you a certain amount of plausible deniability in that you can freely acknowledge that there encrypted volumes on your machine and that you literally have no way to unencrypt them. Of course, they still may attempt to track down the users and get the keys (which would be interesting if you created dummy accounts and only accessed them via Tor) or, more likely, just charge you with aiding and abetting criminals.
Actually, if you decompile the DSDT of many machines you will see that they do indeed detect what OS is running and act accordingly. This is the cause of a lot Linux problems because BIOS vendors will special case something for, say, XP that isn't needed in Vista but is needed in Linux. As the machine has been identified as running Linux and not XP, that special code isn't run. The Linux kernel even has boot options to allow you to identify to the BIOS that you are running a different OS for this very reason.
Rather than just zoning out and trying not to fall asleep, create yourself a list of problems that you can think about and take notes on your thoughts during the meeting. Not only does it look like you are diligently writing down pertinent meeting information but, you don't break your concentration flow.
The one pre-requisite for this is that you have to have someone in the meeting who actually *does* take notes and is responsible for the minutes. If you are asked to write up the minutes after the meeting, your boss is not going to be pleased when they read:
- 8:00: Meeting started
- 8:05: Manager talked
- 9:00: Meeting ended
I did. Now, can you tell me how to make a C program use 36-bit pointers so that I can use PAE? They are two very different things...
Looking at the Apollo 16 landing site, I bet they had a very real "Oh Shit!" moment just before landing...
You are still incorrect. Applications can do some "windowing magic" to make it appear as though they are addressing more than 32-bits seamlessly. They do not however have the ability to use 36-bit pointers. So, they aren't using PAE, they are using tricks to make it possible to use more memory than you can address while the 36-bit kernel is still handing the process 32-bit addresses.
My memory is a little foggy lately, since I've been hanging around in userland a bit, but I'm fairly certain that using long-mode (64-bit) on modern Intel CPU's for your OS and application would yield plenty of virtual address space, using PAE. Additionally, PAE supports a lot more than 36 bits of addressing on the most recent processors, up to 51 I think. The bigger question, is it practical for one CPU to use all that memory?
I think you may be confusing 32-bit with PAE and 64-bit. 32-bit with PAE is userland 32-bit with the kernel able to address 36-bit (64GB). 64-bit addresses 64-bit (16EB if I remember right) in the kernel and userland but, the CPU itself probably can't address all 64-bits so you are confined to some insanely huge addresses space that you can't fill but, it's less than 64 bits.
He's not talking about a cluster. A render farm is just a bunch of machines that can be given work to do. There is no fancy network topology so the machines can talk to each other and they aren't even expected to know of each others existence. A render farm is more akin to something like SETI@home whereas a cluster is a trying to emulate a Big Iron box. Big difference.
So if your shitting rendering app is 32 bit, not PAE aware, single threaded and you have more than 1 core than you can just pile on more processes with any modern OS and exceed 4G of usage. With a real rendering app, i.e. multithreaded, PAE aware and still 32 bit, its a no brainer.
I understand where you are going and agree with you but, applications cannot be PAE aware. It's only the kernel that deals with the 36-bit addressing. It still doles out memory as 32-bit to userland. Also, a multithreaded application wouldn't take advantage of more than 4G of memory unless the OS treats threads as separate processes because each thread is still living within a single process and that process is still bound by 32-bits of addressable memory.
A total of 10 copies of XP (for 10 nodes) may sound like a big expense, but it actually adds $140 per unit, pushing the cost of these machines to about $485 per unit for a dual-core node or $610 per unit for a quad-core configuration.
I think Tom should have rephrased that to put it into perspective: "Don't worry only 20% of the node cost is from Windows". I find it amazing that the most expensive component on the cheaper node is Windows XP and on the beefier node, it's nearly the same price as the CPU. It's even more baffling that this statement appears on the same page in reference to CPU selection:
It's really all about how much you want to spend here, because this is the single most expensive component required for each node.
Maybe Tom is a secret Linux fan and is hinting that Windows isn't a component but a tax. Or maybe he's just really bad at math.
The more likely scenario is:
[knock, knock] ... ... ...
- Are you the owner of the SSID linksys
- Yes
[knock, knock]
- Are you the owner of the SSID linksys
- Yes
[knock, knock]
- Are you the owner of the SSID linksys
- Yes
Repeat several thousands times. Then replace linksys with dlink and repeat again.
Many governments publish gigabytes of CSV files, PDF files, and database files. I assume that's what you're referring to when you say you just want facts published. Should the New York Times just be filled with tables of data?
No, they should describe the contents of those documents in English and in an unbiased manner. That's what "the news" is. It's not sensationalist crap with a slant on the writers/editors/publishers view.
If you want that information translated into written English, the author of that text is going to have a point of view and a context within which they write. It's the way language works. And everyone wants other people to share their understanding of events.
Then they shouldn't be writing it. It has nothing to do with the language. What you are describing is a blog. The news is not a blog. If I read a news article that says, "this reporter thinks", "our analyst thinks", "our correspondent thinks", and I gave a fuck about what any of those people think, I would subscribe to their *blog*.
Tell me the facts and go away.
Especially in an age of botnets and malware
This actually made me do a double take. Why doesn't the RIAA/MPAA just create/requisition a botnet and cause the infected machines to start sharing ludicrous amounts of files. They could sue millions of people.
Shit. Perhaps I have said too much.
The problem is that this will create something that aims to be "the best". It doesn't address the problem of "what I want", it addresses the [non-]problem of "what everyone wants" and so you will still end up with homogeneous sets of things to acquire at the end of the day. Real customization of content should be player generated and not based on a system of pre-teens trying to find the most amusement in how easily they can wtfpwn some other pre-teen.
I'm not sure why suspend/resume times would be slowed with 4G of RAM and an encrypted disk. Now, hibernate/thaw times might be slowed but, suspend/resume is basically just turning off the computer except giving some power to the RAM. Although I'm not running with an encrypted disk, I have 4G of RAM in my laptop and it resumes in about 5-10 seconds and has the added benefit of keeping the disk cache in tact (which both shutdown and hibernate do not do). Although, I have no idea how long it takes to suspend. I just shut the lid and and walk away.
On a side note: I can't wait until a new OS finally achieves the startup times of the good old trusy Commodore 64. :-)
I've never understood the fascination with startup times when suspend/resume is such a more useful alternative. However, Moblin does indeed boot in 5 seconds (even in a VM) and, I will admit, it's actually pretty cool to see it.
'The standard argument is that it just boils down to "knowing how to move" or "knowing when to hit your buttons."'
That sounds like the very definition of skill to me.
The real metric is adaptation. I remember being a rogue in WoW back in the day and evasion tanking MC bosses. Not because that was part of the game plan but because the tank would die and the raid needed to adapt to the situation. When the tank got back up and was healed, I'd vanish and let him start tanking again. Raids are saved by peoples ability to adapt to the situation as it unfolds. It doesn't matter how fast you can click your buttons if you don't understand the situation you are in and how you should act during that situation. Although, I suppose you could actually qualify that as skill.
Seeing how it was done old-school is always refreshing. No C++, Java, C#, just hardcore assembly.
As an anecdote, I have a friend who used to work at MECC and worked on games for the Apple II like Oregon Trail and Odell Lake (find yourself a Way-Back Machine if you aren't familiar with those games). If memory serves me right, before leaving MECC, he wrote something akin to the following in one of those two programs:
[code]
; Important. Do NOT remove this. -- username
nop
nop
nop
; Proceed
[/code]
Years later it was apparently still in the code and he'd met up with an old colleague who asked, "What was up with the three nops? We didn't remove them because we didn't know what would happen". The response being, "Nothing, I just thought it would be funny to have this conversation a few years later".
You forgot the part about him having in depth knowledge of explosives.
Actually, if the application is purely CPU bound and well tuned for CPU X, then switching to the superior CPU Y may not give you an performance benefits at all until it's recompiled and possibly tuned for CPU Y. That assumes the compilers have been updated to understand how to optimally schedule instructions for CPU Y, what new instructions may be available on CPU Y, etc. Hardware vendors know these things whereas hardware consumers think that CPU Y is supposed to be faster and so their software should be running faster.
An example of this was when Sun was switching from UltraSPARC II to UltraSPARC III. Even though the UltraSPARC III chips were clocked 50% higher and had all sorts of goodies that made it seem like a better chip, when the first internal machines appeared performance was dismal and was often below UltraSPARC II in benchmarks. Once the compilers became smart enough to emit optimized code for the UltraSPARC III and once the systems engineers doing benchmarking understood the quirks of the new CPU, performance started to get more inline with expectations.
An easy way to get motivated for writing code is to write code you don't absolutely need to write but, enjoy writing. Do programming challenges, find some part of your OS that has never worked just how you wanted it to and change it, help people on programming forums, etc. When I get stuck on a bug, I find that most of the time, just a 10 minute cigarette break helps me find the answer or at least revitalizes me. For bigger Developer Blocks, doing something completely unrelated but still coding has been very useful to me in the past.
Boingo Inc. vs. 35:42:11:AA:EA:03, 432 US. 666.
Lawyer: You connected to a wireless network in Starbucks?
Defendant: Yes, that's correct.
Lawyer: No further questions.
That level of polish is critical for user acceptance. If you give a user an unthemed GTK desktop (which is hideous) they will blame any and all failings in their ability to use the software correctly on it being "primitive" just because it doesn't look flashy. For better or worse, compiz wobbly windows probably drove more users to linux than, say, the superior workflow paradigm of multiple workspaces.
Having said that, I agree that workflow design is also important. It was included in the e-mails I'm referring to but, to make my point about the culture clash between Humans and Nerds, I only included the most ludicrous examples of the types of things that proper HIE will make you do.
Just out of curiosity did you notice that the product was lacking some polish before you made the changes?
No, the product seemed pleasant looking and very usable from my standpoint. After implementing the changes HIE suggested I was blown away at how great the shipping product was. In fact, that single experience probably changed the way I write GUI applications and, 10 years later, I think if I were to write a GUI application for the same company, HIE would be sending me far fewer e-mails about mundane details.
"Human Interface Engineer" sounds like a bullshit title but, if you get one that actually knows what they are talking about and you listen to them, it can drastically improve the quality of your software. I think the point of the GP was that open source software often doesn't have the level of strictness where a non-programmer can say, "No, it's not polished enough to ship". When you know that the final judge of whether your software will ship or not comes from someone that cares more about presentation/interface/usability than the technology behind it, you write your software differently.