The temperature 30+ says nothing to me. If I know the area of your machine room, the total number of watts from your equipment, maybe I can be more specific. FYI, I have eliminated the drainage issue by installing a small 12V pump myself and getting the pipes to the nearest kitchen sink, so no drilling on external walls.
Well,
No wonder why pure Maths/Physics departments are (sadly) dying out everywhere in the world. Today, we have Universities that have no theoretical research anymore, some say due to the loss of student revenue, I say due to loss of hard working students.
The point with blue sky research is that, well, it creates new knowledge. Its impact is under-stated in favor of the applied research. But I think that blue sky research has more potential for accidental discoveries than applied research.
Whether that makes business sense for Bell, I am not sure. You see IBM has sold its pc division, it has world class applied research, but blue sky research is still there.
Maybe the telcos really need to re-think their revenue generation strategy (treating the Internet as still an app of telephony won't cut the deal anymore, never mind the monopolies) and do not winge about money going to theoretical research.
Another sign of the 'I have too many managers with MBAs' effect. Ah well.
Hi folks,
I wrote this for fun on x86 and x86_64 Linux only. Not for Windows or other platforms. I suspect my choice of the ctime function or the way I try to set the timezone might be upsetting Activestate Perl/Windows, (in case the second poster ran it also on Windows). Will take a look tomorrow...:-)
#!/usr/bin/perl # (or wherever your camel lives) #Copyleft (just joking!) Georgie http://folk.uio.no/georgios use POSIX; use strict;
$ENV{'TZ'} = "GMT"; # GMT for preference print "And the transition will be like...\n"; for (my $clock = 2147483646; $clock < 2147483650; $clock++) { print ctime($clock); }
chomp(my $conclusion=ctime(2147483650)); if ( $conclusion=~/1901$/) { print "Which means that you are bugged by 32 bits. We have 64 bit processors and structures now you know!\n";} else { print "You will survive for now. Go and get a beer. \n";}
The MD-11 is not exactly an aircraft I like from a design perspective either. But I personally attribute this particular Swissair tragedy to the poor methodologies of integrating third party units (such as entertainment systems) to aircraft. Boeing follows a similar model and it authorizes (even for the IMA avionics part) procedural responsibilities for the manufacturing partners to integrate components *after* the basic design and operational testing, which in my view is wrong. When you design such a complex engineering system such as a passenger airline, the important thing is to allow time to see how third party components interact with the basic aircraft structure. And this interaction should be supervised and performed solely by the aircraft manufacturer, not by the third party partners during the original design and testing phase (you wish a new entertainment system? Tough! You can use only the ones we have cleared out and tested.). In this case, somebody integrated an entertainment system without checking well for thermal dissipation loads or after effects of system component failures, well after the aircraft constructions. As far as I know, the space shuttle follows this technique. Nothing can change after some initial design stages, which is probably why some very archaic components are used. But if they are re-conditioned/re-manufactured, we know that they work, we know how they react and so we can manage the risk, unless we discover something seriously wrong, we do not change it. He, he. Try to convince the NASA engineering directors to integrate iPod units to the sleeping quarters and see their reaction:-) .
I am a bit unclear on how the circuit breaker situation could have affected the outcome here. There was circuit redundancy but the main problem for this incident is that the flight crew was overcome by smoke in the cockpit. That smoke was also a result of wider design failures that concerned the mylar insulation. So, the fact that the fire probably started by an arching wire of the entertainment system is significant. The fact, however, that these wires were close to ventilation units and that mylar insulation was nearby is for me more important. In fact, aircraft wiring is the dark horse of aircraft maintenance. If you think the Kilometers of wires and the cost/complexity of replacing them, you will understand what I mean and realize that some things are cost governed (when they should not be, as we are dealing with human lifes here).
The 1553 bus is still widely employed and as long as they do not use direct coupling (maybe some of the older aircrafts do that), things should be allright.
Things can be engineered properly. However, in the aviation industry, I would be worried more about other areas, such as the security standards of inter ATC communications. There is one threat vector by compromising a single aircraft and another for compromising the ATC of a district area center or a major airport with hundreds to thousands of planes depending on them!
Anyway, as I had been involved with some avionics work, it is incredibly difficuly (not impossible) to compromise the control signals for basic surface control on an Avionics Full-Duplex Switched Ethernet (AFDX) ARINC-664 network, the type of standard used for Aircraft Data Networks. You can google it, but for a quick summary, it is a deterministic full duplex version of Ethernet with additional bits and bobs to safeguard redundancy and message integrity. The message integrity spec means that due to special protocols, when a cockpit console control (say the throttle) needs to transmit to the engine FADEC, the actual module on the engine not only expects to receive a relevant message from the right domain (there are different domains such as electrical flight control, communications, pneumatics), but also from a very specific component (that has a serial number). The point is that you cannot re-route messages easily and there is some sort of authentication of components talking to each other. It is incredibly difficult for someone to replay an engine switch off message that should be routed to the engine and make it to appear that it comes from the console switch of the cockpit, when in fact it comes from an external hacker. This combined with the fact that the core OS is probably some real-time micro-kernel derivative with specially obscured commands (Wind River VxWorks, other?), makes things more difficult.
Having said that, security through obscurity and whatever authentication/authorization system is not a panacea for the lifes of 200-300 people that travel at mach 0.8 at 35000 feet. Even if there is someone that succeeds in getting in, in the Airbus version of the system, the pilot has the option to shut off external comms by resetting the external link. None of the critical parts (main MCUs, core switching components) have erasable firmware, so...somebody could be cut off easily, if she is detected on time and provided that it does not create a situation to put the aircraft in a non reversible situation (nose dive, spin). And this is where they fail. They *might* consider now IDS/IPS mechanisms, but so far they might have NOT done it. That is the first point.
The second point I don't like is the way Boeing deploys IMA, the Integrated Modular Avionics system. Both Boeing and Airbus have reduced the number of discrete avionics units to make the aircraft lighter and simplify maintenance (so both use 1 core network for everything). However, whilst the A380's IMA has 8 processing modules all tied together by an AFDX network, Boeing has 3 distinct units with less degree of autonomy from the comms network. It does not mean that everyone can get in and start playing flight sim, but there are less obstructions to place out of the way.
I hope that they will include IDS/IPS on the core network. Whatever firewall or other solution they might have, it is good to know that someone is likely to be in, even after the effect and chop the connection at the right time under conditions. Integration cannot be avoided. It can only be managed.
True. Well, all this goes back to what I wrote earlier on and this is why we insisted on designing a storage infrastructure to provide realistic storage limits. If they gave you a suitable VPN and 10 Gigs, would you bother with the headaches of portable storage security? Probably not. Normally, there is some cash flow problem or their requirements are out of date and/or they don't care. Faculty or school funding must allocate money for storage per student/researcher. In the latter cases, they clearly don't get the picture and this is one of the reasons Google, Amazon and other ventures are trying to capitalize on selling on-line storage. I don't know if a researcher or group of researchers would be willing to store confidential info on a third party provider, but at least if they did they would have more assurances over their availability of their data than storing them on a portable storage medium, even with bandwidth scalability concerns. Technologies to aggregate on demand storage at reasonable prices exist, so "kick" them, shout, complain. They should make your life easier, that's why they have a job. And if they complain, tell them to state that the students should provide the blackboards to write in lecture theater blocks, to run their own library, etc, etc...:-)
The portable storage blues is a mixture of incomplete policy decisions, technology adoption and resource planning . I shall explain my view. I am co-administering and directing on the technical side a 300 user R&D IT infrastructure (servers, desktops, network), which is part of a large University setup (20000 students plus) for 5 years now. Indeed, things in academia have to be open. And they can be as long as you focus on the problem.
Desktop wise, a proven conbination of transparent bridging at network level, an antivirus/spyware on the desktop and another anti-virus/spyware on the mail server will filter out most of the traditional ways of infecting systems with malware. Scripts to enforce patching and lock out users that connect to the network might be a big headache, so if you can afford the overhead do that, or switch critical services to a more secure (and yes, I mean that) desktop such as a patched version of Linux.
The issue of data migration to/from portable storage is a head-scratching one. So, where I work, we scratched our head a lot and came up with the following conclusions: - We can train users to understand the implications of relying on portable storage. - Encryption could protect the content. In rare cases, it was a big headache, when users lost encryption keys, or when users wanted us to face performance issues on large encrypted filesystems. - Portable storage will never be secure from the issue of data availability. Whether your data are encrypted or not does not matter if the device gets lost or broken and the user does not sync the data (for whatever reason). Scenarios where people had grant applications on USB keys and then they lost them or miscplaced them inside a warm cup of coffee or had their kids bike going over their laptop in the garden are common.
This last point made us re-examine why people use portable devices in academic setups in the first place. Apart from the obvious reasons ( mobility convenience, etc, etc), we found that strong motives for users to use portable storage media in an academic setup exist due to two reasons: i)Network drive user quotas were extremely low, almost not usable. In fact, I know of faculties that still give a Gig of space per user and find it generous. ii)Lack of suitable VPN solutions, so people could authenticate and mount their drives securely from remote locations. VPNs are common place, but they were dog slow, especially for large user setups, so faculties tend to serve tenths of thousands of users with only three or four VPN gateways that can handle (together) far fewer sessions than the true average user load. The result, non existing or slow connections, users give up, buy a key or portable drive and hope for the best.
I approached our Director, explained the problem and got funding to buy a storage solution able to a quota of 20 Gigs per user and also upgrade our campus connection and have our own separate VPN gateway, able to handle up to 80% of the average session load with strong crypto. It wasn't easy, and he heard the bill, he changed a few colours. However, if you explain with numbers the cost of loosing a grant, or the research work of the last two years (some experiments are quite expensive to repeat), they can be convinced to approve the budget.
I don't know about the US, but in Europe, the broadband home market is good enough to sustain a good connection rate even with a 1Mbps/384Kbps ADSL setup for direct common file I/O (documents, spreadsheets, etc). Amongst academic networks things are even better. Storage is becoming cheaper, so making a policy decision to allow portable media and empowering your users with adequate amounts of centralized storage that is easily reachable is, in my humble opinion, the best way to combat the portable storage blues.
OK, we got a half way overview of CERN's decision, with some bold statements of questionable validity. I am submitting the criticism purely on the grounds of being really interested in large data storage, I don't work for any large storage vendor, but I am an architect of storage systems.
First of all, with the statement "and it's (StorNext) completely vendor independent": Lot's of other solutions provide flexibility about choosing the hardware vendor from a theoretical perspective. The theory says that if vendor A makes a SAN, vendor B makes a RAID controller, C a disk cabinet and D offers a clustered FS, and all comply to the relevant standards, you can plug them together and expect them to function. However, imperfections in the standards, hidden proprietary optimizations, always dictate certain configs and combinations for optimum performance. There is a lot of work to be done in the StorNext and other similar products, until they claim full flexibility. My experience in deploying a StorNext based solution on a 1200 node setup says so and to keep the post short, I shall exclude at this stage vendor details, but if someone is interested, I am happy to go over the details. There is vendor dependence if you wish optimum performance. Not to mention that if you mix and match the RAID and SAN cards in the setup, any unfortunate issue might end up in a multi-headache, even if you have solution support (A blaims B, B accusses A, and the game of ping-pong begins). You can never exclude vendor dependence in such a large setup, you have to deal with it.
Then you have the "Clustered file systems are still an evolving category, she says, but enterprise IT is warming up to it.". I can imagine what the author classes as enterprise IT here, but I think there is a bit of an orientation issue. CERN is not exactly the classical enterprise IT environment, is it? Not in terms of their requirements for resilience and capacity. These FAR EXCEED enteprise IT requirements. CERN is a research setup. And the mentality of a research setup (that incubated the WWW after all) is (or should be) that of innovation and playing with some of the latest and the greatest. In fact, some US based research setups have long experimented with other cluster FSes. They are not warming up. CIO claims that StorNext is scalable. It is. But to what extent? Have they excluded for example things such as Lustre? http://wiki.lustre.org/index.php?title=Main_Page If yes, why?
Your tip is as good as your 'label theory'. (non academic=good, academic=bad)
I left the academic environment because of the low salaries. I have academic credentials. It is true that inside academia, there are people who theorize too much. It is not true that you won't find any true hackers in academia. The very reason why I got started with computers was my own interest, but the impact of people I met inside academia was important. Hackers do live in academic environments as well. It might be your fellow student, the old sysadmin behind the computer support, not necessarily your lecturer or the Professors. Hacking is an attitude, a habbit. Not something which has or does not have credentials and thus, your tip is incorrect, if it hints that academia and hacking are mutually exclusive.
"a professor Tannenbaum at the Vrije University"...
Professor Tannenbaum prefers to teach OSes using microkernels, so he would probably love to explain MINIX and other mikrokernels architectures for teaching, as opposed to monolithic kernels (Linux). That is his view, not mine.
I am a bit surprised with what I read, as I happen to know many academic institutions (UK based) that do teach the inner parts of the Linux kernel to final year undergrads. Some courses are a little bit out of date (teaching 2.4 kernel stuff) but one could get the basic idea and then find references (see latter paragraphs) to jump from 2.4 to 2.6 . In fact, I graduated from one of them 7 years ago and I do remember the long nights behind a source editor looking at kernel structures and making the kernel panic in all sorts of ways:-P .
However, I would agree that the C programming skills are in a downturn, something reflected by the fact that most courses are geared towards application programming and systems programming (not the digital electronics and the C to interface to microcontrollers) seems to be heading towards a new area51 tag:-) .
Anyways, to respond to the original question, I would say, from my own humble experience, that kernel programming is not something that you could digest easily, even in a semester course, especially in your final year (I am not trying to put you off, read on). Not only because, as correctly said, there is relative lack of intermediate C programming skill in the majority of uni courses. Even if you were an intermediate C programmer, there is too much to grasp, from OS theory, down to programmming style and the way things are done in Linux (there is a different C programming style for applications, and a different one for kernel system calls). So, what to do to overcome this issue:
1)Make sure you get your hands on:
i) Linux Kernel Development (2nd Edition) by Robert Love
ii)O Reilly Practical C Programming, the 3rd Edition.
iii)A 2.6 based linux kernel distro.
2)Start with Robert Love's book. Read chapters 1-4, up to the point you understand the theory behind system calls.
3)Make sure you then read systematically the C programming book, especially the chapters about pointers, structures and linked lists (advanced pointers). At the same time, make sure you get frequently into the process of compiling your own kernel.
At this point, continue with the rest of the chapters of Robert Love's group. THEN it is the right time, when you have an idea, to look for a course, and you will get a lot more from it, having done your reading. Make sure to get in touch with your local LUG (Linux User Group). There must be somebody there that shares your interests that can inform you about courses or assist you and others to go deeper into the kernel.
Yeah, I am not sure I would buy this either. From a security view point I would like things to be read only. It is not the panacea of all assurances, but in an era of stealthy malware, can you imagine the effect of a code re-engineering contaminating a patch that starts rolling out re-programmable FPGAs? Well, this could be the scenario today with stealthy rootkits and re-programmable BIOSes. But I have to definitely give the thumbs down for the "shorter time to market" bit. We all face the negative effects of bad software quality as a result of the increasing pressure for companies to release quickly. Finally, before talking about the effectiveness of deploying software with FPGAs, my own view is that the tools used to help the programmer in the process of porting code to an FPGA platform have a looooong way to go from a usability perspective.
GM
Slashdot Mirror
The temperature 30+ says nothing to me. If I know the area of your machine room, the total number of watts from your equipment, maybe I can be more specific. FYI, I have eliminated the drainage issue by installing a small 12V pump myself and getting the pipes to the nearest kitchen sink, so no drilling on external walls.
Well, No wonder why pure Maths/Physics departments are (sadly) dying out everywhere in the world. Today, we have Universities that have no theoretical research anymore, some say due to the loss of student revenue, I say due to loss of hard working students. The point with blue sky research is that, well, it creates new knowledge. Its impact is under-stated in favor of the applied research. But I think that blue sky research has more potential for accidental discoveries than applied research. Whether that makes business sense for Bell, I am not sure. You see IBM has sold its pc division, it has world class applied research, but blue sky research is still there. Maybe the telcos really need to re-think their revenue generation strategy (treating the Internet as still an app of telephony won't cut the deal anymore, never mind the monopolies) and do not winge about money going to theoretical research. Another sign of the 'I have too many managers with MBAs' effect. Ah well.
Hi folks, I wrote this for fun on x86 and x86_64 Linux only. Not for Windows or other platforms. I suspect my choice of the ctime function or the way I try to set the timezone might be upsetting Activestate Perl/Windows, (in case the second poster ran it also on Windows). Will take a look tomorrow... :-)
#!/usr/bin/perl
/1901$/) {
# (or wherever your camel lives)
#Copyleft (just joking!) Georgie http://folk.uio.no/georgios
use POSIX;
use strict;
$ENV{'TZ'} = "GMT";
# GMT for preference
print "And the transition will be like...\n";
for (my $clock = 2147483646; $clock < 2147483650; $clock++)
{
print ctime($clock);
}
chomp(my $conclusion=ctime(2147483650));
if ( $conclusion=~
print "Which means that you are bugged by 32 bits. We have 64 bit processors and structures now you know!\n";} else {
print "You will survive for now. Go and get a beer. \n";}
I am a bit unclear on how the circuit breaker situation could have affected the outcome here. There was circuit redundancy but the main problem for this incident is that the flight crew was overcome by smoke in the cockpit. That smoke was also a result of wider design failures that concerned the mylar insulation. So, the fact that the fire probably started by an arching wire of the entertainment system is significant. The fact, however, that these wires were close to ventilation units and that mylar insulation was nearby is for me more important. In fact, aircraft wiring is the dark horse of aircraft maintenance. If you think the Kilometers of wires and the cost/complexity of replacing them, you will understand what I mean and realize that some things are cost governed (when they should not be, as we are dealing with human lifes here).
The 1553 bus is still widely employed and as long as they do not use direct coupling (maybe some of the older aircrafts do that), things should be allright.
Anyway, as I had been involved with some avionics work, it is incredibly difficuly (not impossible) to compromise the control signals for basic surface control on an Avionics Full-Duplex Switched Ethernet (AFDX) ARINC-664 network, the type of standard used for Aircraft Data Networks. You can google it, but for a quick summary, it is a deterministic full duplex version of Ethernet with additional bits and bobs to safeguard redundancy and message integrity. The message integrity spec means that due to special protocols, when a cockpit console control (say the throttle) needs to transmit to the engine FADEC, the actual module on the engine not only expects to receive a relevant message from the right domain (there are different domains such as electrical flight control, communications, pneumatics), but also from a very specific component (that has a serial number). The point is that you cannot re-route messages easily and there is some sort of authentication of components talking to each other. It is incredibly difficult for someone to replay an engine switch off message that should be routed to the engine and make it to appear that it comes from the console switch of the cockpit, when in fact it comes from an external hacker. This combined with the fact that the core OS is probably some real-time micro-kernel derivative with specially obscured commands (Wind River VxWorks, other?), makes things more difficult.
Having said that, security through obscurity and whatever authentication/authorization system is not a panacea for the lifes of 200-300 people that travel at mach 0.8 at 35000 feet. Even if there is someone that succeeds in getting in, in the Airbus version of the system, the pilot has the option to shut off external comms by resetting the external link. None of the critical parts (main MCUs, core switching components) have erasable firmware, so...somebody could be cut off easily, if she is detected on time and provided that it does not create a situation to put the aircraft in a non reversible situation (nose dive, spin). And this is where they fail. They *might* consider now IDS/IPS mechanisms, but so far they might have NOT done it. That is the first point.
The second point I don't like is the way Boeing deploys IMA, the Integrated Modular Avionics system. Both Boeing and Airbus have reduced the number of discrete avionics units to make the aircraft lighter and simplify maintenance (so both use 1 core network for everything). However, whilst the A380's IMA has 8 processing modules all tied together by an AFDX network, Boeing has 3 distinct units with less degree of autonomy from the comms network. It does not mean that everyone can get in and start playing flight sim, but there are less obstructions to place out of the way.
I hope that they will include IDS/IPS on the core network. Whatever firewall or other solution they might have, it is good to know that someone is likely to be in, even after the effect and chop the connection at the right time under conditions. Integration cannot be avoided. It can only be managed.
True. Well, all this goes back to what I wrote earlier on and this is why we insisted on designing a storage infrastructure to provide realistic storage limits. If they gave you a suitable VPN and 10 Gigs, would you bother with the headaches of portable storage security? Probably not. Normally, there is some cash flow problem or their requirements are out of date and/or they don't care. Faculty or school funding must allocate money for storage per student/researcher. In the latter cases, they clearly don't get the picture and this is one of the reasons Google, Amazon and other ventures are trying to capitalize on selling on-line storage. I don't know if a researcher or group of researchers would be willing to store confidential info on a third party provider, but at least if they did they would have more assurances over their availability of their data than storing them on a portable storage medium, even with bandwidth scalability concerns. Technologies to aggregate on demand storage at reasonable prices exist, so "kick" them, shout, complain. They should make your life easier, that's why they have a job. And if they complain, tell them to state that the students should provide the blackboards to write in lecture theater blocks, to run their own library, etc, etc... :-)
The portable storage blues is a mixture of incomplete policy decisions, technology adoption and resource planning . I shall explain my view. I am co-administering and directing on the technical side a 300 user R&D IT infrastructure (servers, desktops, network), which is part of a large University setup (20000 students plus) for 5 years now. Indeed, things in academia have to be open. And they can be as long as you focus on the problem.
Desktop wise, a proven conbination of transparent bridging at network level, an antivirus/spyware on the desktop and another anti-virus/spyware on the mail server will filter out most of the traditional ways of infecting systems with malware. Scripts to enforce patching and lock out users that connect to the network might be a big headache, so if you can afford the overhead do that, or switch critical services to a more secure (and yes, I mean that) desktop such as a patched version of Linux.
The issue of data migration to/from portable storage is a head-scratching one. So, where I work, we scratched our head a lot and came up with the following conclusions:
- We can train users to understand the implications of relying on portable storage.
- Encryption could protect the content. In rare cases, it was a big headache, when users lost encryption keys, or when users wanted us to face performance issues on large encrypted filesystems.
- Portable storage will never be secure from the issue of data availability. Whether your data are encrypted or not does not matter if the device gets lost or broken and the user does not sync the data (for whatever reason). Scenarios where people had grant applications on USB keys and then they lost them or miscplaced them inside a warm cup of coffee or had their kids bike going over their laptop in the garden are common.
This last point made us re-examine why people use portable devices in academic setups in the first place. Apart from the obvious reasons ( mobility convenience, etc, etc), we found that strong motives for users to use portable storage media in an academic setup exist due to two reasons:
i)Network drive user quotas were extremely low, almost not usable. In fact, I know of faculties that still give a Gig of space per user and find it generous.
ii)Lack of suitable VPN solutions, so people could authenticate and mount their drives securely from remote locations. VPNs are common place, but they were dog slow, especially for large user setups, so faculties tend to serve tenths of thousands of users with only three or four VPN gateways that can handle (together) far fewer sessions than the true average user load. The result, non existing or slow connections, users give up, buy a key or portable drive and hope for the best.
I approached our Director, explained the problem and got funding to buy a storage solution able to a quota of 20 Gigs per user and also upgrade our campus connection and have our own separate VPN gateway, able to handle up to 80% of the average session load with strong crypto. It wasn't easy, and he heard the bill, he changed a few colours. However, if you explain with numbers the cost of loosing a grant, or the research work of the last two years (some experiments are quite expensive to repeat), they can be convinced to approve the budget.
I don't know about the US, but in Europe, the broadband home market is good enough to sustain a good connection rate even with a 1Mbps/384Kbps ADSL setup for direct common file I/O (documents, spreadsheets, etc). Amongst academic networks things are even better. Storage is becoming cheaper, so making a policy decision to allow portable media and empowering your users with adequate amounts of centralized storage that is easily reachable is, in my humble opinion, the best way to combat the portable storage blues.
Replace int with long int to be more accurate. :-)
OK, we got a half way overview of CERN's decision, with some bold statements of questionable validity. I am submitting the criticism purely on the grounds of being really interested in large data storage, I don't work for any large storage vendor, but I am an architect of storage systems.
First of all, with the statement "and it's (StorNext) completely vendor independent": Lot's of other solutions provide flexibility about choosing the hardware vendor from a theoretical perspective. The theory says that if vendor A makes a SAN, vendor B makes a RAID controller, C a disk cabinet and D offers a clustered FS, and all comply to the relevant standards, you can plug them together and expect them to function. However, imperfections in the standards, hidden proprietary optimizations, always dictate certain configs and combinations for optimum performance. There is a lot of work to be done in the StorNext and other similar products, until they claim full flexibility. My experience in deploying a StorNext based solution on a 1200 node setup says so and to keep the post short, I shall exclude at this stage vendor details, but if someone is interested, I am happy to go over the details. There is vendor dependence if you wish optimum performance. Not to mention that if you mix and match the RAID and SAN cards in the setup, any unfortunate issue might end up in a multi-headache, even if you have solution support (A blaims B, B accusses A, and the game of ping-pong begins). You can never exclude vendor dependence in such a large setup, you have to deal with it.
Then you have the "Clustered file systems are still an evolving category, she says, but enterprise IT is warming up to it.". I can imagine what the author classes as enterprise IT here, but I think there is a bit of an orientation issue. CERN is not exactly the classical enterprise IT environment, is it? Not in terms of their requirements for resilience and capacity. These FAR EXCEED enteprise IT requirements. CERN is a research setup. And the mentality of a research setup (that incubated the WWW after all) is (or should be) that of innovation and playing with some of the latest and the greatest. In fact, some US based research setups have long experimented with other cluster FSes. They are not warming up. CIO claims that StorNext is scalable. It is. But to what extent? Have they excluded for example things such as Lustre? http://wiki.lustre.org/index.php?title=Main_Page If yes, why?
Your tip is as good as your 'label theory'. (non academic=good, academic=bad)
I left the academic environment because of the low salaries. I have academic credentials. It is true that inside academia, there are people who theorize too much. It is not true that you won't find any true hackers in academia. The very reason why I got started with computers was my own interest, but the impact of people I met inside academia was important. Hackers do live in academic environments as well. It might be your fellow student, the old sysadmin behind the computer support, not necessarily your lecturer or the Professors. Hacking is an attitude, a habbit. Not something which has or does not have credentials and thus, your tip is incorrect, if it hints that academia and hacking are mutually exclusive.
"a professor Tannenbaum at the Vrije University"...
Professor Tannenbaum prefers to teach OSes using microkernels, so he would probably love to explain MINIX and other mikrokernels architectures for teaching, as opposed to monolithic kernels (Linux). That is his view, not mine.
GM
I am a bit surprised with what I read, as I happen to know many academic institutions (UK based) that do teach the inner parts of the Linux kernel to final year undergrads. Some courses are a little bit out of date (teaching 2.4 kernel stuff) but one could get the basic idea and then find references (see latter paragraphs) to jump from 2.4 to 2.6 . In fact, I graduated from one of them 7 years ago and I do remember the long nights behind a source editor looking at kernel structures and making the kernel panic in all sorts of ways :-P .
:-) .
However, I would agree that the C programming skills are in a downturn, something reflected by the fact that most courses are geared towards application programming and systems programming (not the digital electronics and the C to interface to microcontrollers) seems to be heading towards a new area51 tag
Anyways, to respond to the original question, I would say, from my own humble experience, that kernel programming is not something that you could digest easily, even in a semester course, especially in your final year (I am not trying to put you off, read on). Not only because, as correctly said, there is relative lack of intermediate C programming skill in the majority of uni courses. Even if you were an intermediate C programmer, there is too much to grasp, from OS theory, down to programmming style and the way things are done in Linux (there is a different C programming style for applications, and a different one for kernel system calls). So, what to do to overcome this issue:
1)Make sure you get your hands on:
i) Linux Kernel Development (2nd Edition) by Robert Love
ii)O Reilly Practical C Programming, the 3rd Edition.
iii)A 2.6 based linux kernel distro.
2)Start with Robert Love's book. Read chapters 1-4, up to the point you understand the theory behind system calls.
3)Make sure you then read systematically the C programming book, especially the chapters about pointers, structures and linked lists (advanced pointers). At the same time, make sure you get frequently into the process of compiling your own kernel.
At this point, continue with the rest of the chapters of Robert Love's group. THEN it is the right time, when you have an idea, to look for a course, and you will get a lot more from it, having done your reading. Make sure to get in touch with your local LUG (Linux User Group). There must be somebody there that shares your interests that can inform you about courses or assist you and others to go deeper into the kernel.
GM
Yeah, I am not sure I would buy this either. From a security view point I would like things to be read only. It is not the panacea of all assurances, but in an era of stealthy malware, can you imagine the effect of a code re-engineering contaminating a patch that starts rolling out re-programmable FPGAs? Well, this could be the scenario today with stealthy rootkits and re-programmable BIOSes. But I have to definitely give the thumbs down for the "shorter time to market" bit. We all face the negative effects of bad software quality as a result of the increasing pressure for companies to release quickly. Finally, before talking about the effectiveness of deploying software with FPGAs, my own view is that the tools used to help the programmer in the process of porting code to an FPGA platform have a looooong way to go from a usability perspective. GM
...when the IE people manage to handle them properly and safely :-) .