I disagree. I spent a lot of time in Eastern Europe, and the young people overwhelmingly tell me that it's American English their teachers want them to learn.
I don't claim to be well read, travelled or wise - but foreign exchange students I've talked to over the years at university from western europe seem to indicate a preference for British english... although to tell the truth, for the ones that weren't good at it, the only thing "british" about their english was spelling.
My sample space may be insufficient to make a properly informed conclusion, but that's the impression I got from friends who were from France, Italy, and Sweden - not to mention the slew of other nationalities from asia and africa. Many mention that both US and British spellings are accepted. Those that seemed to use American spellings exclusively seemed to be Japanese, and perhaps Korean/Chinese (I didn't get to know any well enough to learn their habits).
Interestingly, one exchange student that very much avoided American spelling even more than I do was from India - I edited his thesis for him. He seemed to have his own brand of sentence structure... and using 3rd person seemed a challenge for him. After 70 pages it was starting to wear off on me too:-) It's amazing how easily we absorb habits from others...
Either way, Americanisms are definately taking over our culture here in Australia; I know the way that myself and my peers speak and write is quite different to that of my grandparents (early 70s).
My little brother (13) and his friends seem to be almost completely americanised - it's amusing to make fun of their "Dragon Ball Zed". And I suspect their spelling habits come from not bothering to change the default spell-check options in MS Word. But most amusing of all, is the adoption of various mannerisms they learn from movies and pop culture. "I'll cut you", "Bring it on, biatch", and so on. All whilst wearing an Eminem t-shirt (whom I detest)...
I hate to break it to you, but that's a lazy Americanism.
I'll have to take your word for it being unique to America... if I was trying to write with a more formal tone, I'd use "I have never left Australia".
To me, "never" is less ambiguous than "haven't" because "haven't" is open to being interpreted differently if the sentence is taken out of context.
All that aside, Australians speaking informally aren't exactly known for their disciplined use of language. My "less educated" (more likely, less anal) friends hate it when I correct them on improper verb tenses, E.G. "seen" instead of "saw" (E.G. "I seen it" instead of "I saw it"), "done" instead of "did" (E.G.: "I done it" instead of "I did it"), and so on.
I agree about there possibly being an evolution of a "standardised" usage of english (a set of common , boring vocabulary without too much redundancy) by non-english speaking nations doing business with each other, but in my experience it does not seem to be based on American english.
Granted, I haven't had that much experience (I've never even left Australia), but the foreign exchange students I know have all used British conventions, not American. This would include persons from: Italy, Ukrain, Germany, Finland, France, various nationalities from Africa (Zimbabwe, Nigeria, South Africa), Singapore, Hong Kong, and India.
In fact, about the only nationality I have encountered using American English are Americans, Canadians and Japanese. I do have some acquaintences from China and South Korea but I can't remember any of their written english habits... I suspect they use American english too; but it seemed the Chinese guy I knew had learnt all his english from programming and Operating Systems.
What I would really like to see is a v20z with a SATA instead of SCSI option. These are supposed to be cheap servers, and if SATA drives are good enough for their FC SAN storage products, why aren't they good enough for servers?
SAS might as well be SCSI in my situation... it's still not cheap, plentiful SATA.
I don't remember complaining about cheap stuff breaking, either: I understand the benefits of "real" hardware but cannot afford it. As such, what I'm putting together avoids relying on any one server.
But if you ask me, cheap reliable storage with commodity HDDz is a solved problem. My setups so far have used RAID-1 with 1 or 2 hot spares - I haven't bothered with RAID-5 yet.
I'm only dealing with about 6-8U worth of stuff in each rack at each site, not exactly datacentre proportions... as long as each RAID array can handle a failed disk for at least 1-2 weeks I'm good.
I'm aware of this model, however it is only single-CPU and has only two hot-swap drive bays. It's "2-way" in the sense that you can put a single dual-core AMD 27x CPU in it...
What I would really like, is the v20z with SATA instead of SCSI. Then I'd be a bit happier, except the system I'm looking at building myself is a 3U rack with 8x hot-swap SATA bays.
It seems they don't like the idea of having your app server also hosting mass storage.
It seems they would rather you bought separate FC SAN storage for your data storage (the FC "storage solutions" they promote use SATA) and kept your servers running on SCSI in a different box. Which would make sense in an idea world, but it doubles my startup cost..
I'm pricing 2U & 3U rack-mount servers to run Linux.
My desired system is a dual 27x Opteron with 4-6 hot-swap SATA drive bays. What's with all the SCSI out there? There doesn't seem to be any brand-name dual-CPU rack servers out there which have a SATA option.
Yes, I know SCSI is much faster, has a fraction of the CPU overhead that PATA has, and has been hot-swap capable since probably before I learnt how to read.
Perhaps I'm trying to stretch my budget too thin, but the best I can do is build my own from components using 3Ware SATA RAID.
In my limited experience with SCSI, I've actually seen two occasions where having all the disks on the one channel was a bad idea. In both cases, a faild disk managed to lock the entire bus so that none of the good disks could be accessed - rendering the live running failure tolerance of RAID useless.
So, the idea of cheap SATA drives with their independant connections to the RAID adpater appeals to me.... but this doesn't seem to be an option on any of the brand-names:(
I forgot to mention each IEC mains cable and each power point on the main repair bench was powered through a "lifeguard" personal mains power safety box. Thing. Although the earth-leakage detection on most modern mains circuits installed into your building will cause a trip at a certain threshold current on their own, these "personal" mains safety boxes (usually aimed at tradesmen with power-tools at a building site, I think) are designed to have a much lower threshold current and hence the theory is, that in some cases, it should prevent you from being zapped as bad (or as long) as you would just depending on the mains breaker for the entire circuit in that room.
As for tooling: forgot to mention... we had another keyboard tray that was stowed conveniently under the new systems bench with cable test gear, mod connectors, and crimping tools along with some boxes of Cat-5e overhead on a shelf for quickly making cables on demand.
The rest of our tools were pretty basic... a few nifty magnetic gadgets and tweezers for removing lost screws in the bowels of some $5,000 printer, a few multimetres, we also had some specialised stuff for troubleshooting some customer sites that used RS485 multi-drop networks, a whole assortment of adapters and cables... but nothing that stands out except: known working common computer bits for when you need a sanity check:-)
If you ask me, the worst part was getting the other techs to keep the tool kits clean, vaguely sorted and free of junk... I don't know how many times I had to go outside and hunt for needle-nose pliers or cripming tool in on the floor of one of the work vehicles!
On the rare occasions that you need them, some driver kits with the "weird" ends suitable for compaq, "security", and hex screws are extremely useful... keep in a safe place!
The workshop was compact but the main repair bench had 12 "stations", 6 stations on each side opposite each other. They had keyboard trays underneath them, and all cables (IEC mains, RJ45 LAN, telephone, VGA, keyboard) came up from the bottom through a hole about 50cm inward in a bundle for each station.
This main bench was about 5 metres long.
Running down the middle of the table from end to the other was a narrow shelf raised up about 30cm above the work area. It was actually a "double" shelf, a second sheet of MBF was raised another 5cm above the first. This 5cm gap held most of the power cabling and LCD PSUs.
On top of the raised shelf sat 8x 15" LCDs - 6 down one side, and 2 on the opposite. One side was meant to be dedicated to desktop PCs, the other for laser printers and big 'ol servers.
Our "stuff storage" was actually under the table, assorted into 50cm squar(ish) plastic bins.
On a wall on the side of the bench that had the 6x LCDs, were the "in benches", which ran as long as the main bench. A whole wall with 4 levels of shelving. That was quite full a lot of the time... the out shelves were even bigger.
The main bench was not against any walls of the room, so you could all the way around it but both ends of the main repair bench had a "wall" capping them off extending from the floor to the roof that we hung stuff off of (USB ethernet dongles, 2.5" IDE adapters, useful CDROMs (Knoppix;), etc).
Standing at the PC-repair side, the right-hand wall thing had yet another bench with a "station" - another 15" LCD, keyboard tray, LAN, etc. with a KVM that switched between four "wall-mounted" motherboards (fully functioning PCs - just with their bits screwed to the wall). These were used for testing faulty HDDs, antivirus scanning, data recovery, etc.
There was another workbench dedicated to building and configuring PCs, but it only had one 15" LCD, keyboard tray, etc. on a KVM that could switch between four different PCs being "run up" from new. It was kind of cramped and only useful for doing the software side of things... actually building PCs ended up being done on the main repair bench anyway, but at a pinch these were used when room was scarce and the situation urgent.
We also had compactuses, marvellous space efficient storage devices - shelves on tracks that can all slide up against each other or expended wherever you need to walk in and get something. These were used to hold components and cards and seldom-used things.
We had a POST probe, but it was only really useful for writing something intelligent on an RA form for faulty motherboards - by the time you're pulling out a POST probe, chances are that knowing the BIOS halts at "DRAM cache init fail" is not going to help you make a physical repair to the motherboard...
A word about the LAN at each repair station: We had cabling running to a linux box using a bunch of D-Link 4-port ethernet cards. I think we had a total of 14 10/100 ports on that thing. We set up each of the 8 repair bays that had an LCD and LAN on the main bench with its own subnet, and configured the firewall rules with fwbuilder. It worked great. I even set up transparent proxy caching with squid; although I had to create specific rules to allow the Microsoft Windows Updates to actually use the cache.
Why did we firewall each repair bay individually to its own little subnet? Because we didn't want customer's PCs infecting each other with worms... I tried running snort and mrtd with the server's screen set to tail -f the appropriate logs but found if there actually was worm activity going crazy on 2 or 3 stations, it ate up all the RAM and CPU and things would crawl to a halt.
Other LAN segments: - one with the 4x wall mounted PCs and a couple of file servers - one that had the 4x "new systems" bench stations and a couple of ports to our training room that was used for software trainings to our customers - one that contained PCs related to the running of the business (POS, j
Hey, don't get me wrong. I have no idea why I would want any email in an SQL database either. As was pointed out, a filesystem storage scheme suites email perfectly.
I'm developing an app that involves image archiving. The SQL DB contains image IDs which translate to files on a JFS filesystem that hold the actual (1MiB or so) images.
There's a time and place for everything... perhaps I'd put email in an SQL DB if I was adding plenty of searchable meta information to each message for statistical analysis and stuff...
Doing a trace on a DB for a simple query tells you absolutely nothing about its scalability.
How remarkable these algorithms guys are. The thing about SCALING in this scenario is all about the ABSOLUTE terms of the physical implementation.
It's sometimes known as 'DIMENSIONING'.
WHY IS IT SO IMPOSSIBLE FOR SOFTWARE ENGINEERS TO UNDERSTAND THE CONCEPT OF "COUNTING CYCLES"?
If you find that 100 syscalls are being made per DB query and only 10 per FS query, that tells you quite a lot. It means that the FS implementation is using 1/10th the number of syscalls to get the same amount of work done for this particular scenario.
Does that prove in any way it's going to be 10x more efficient in every scenario based on this test alone? NO, but considering the expense of switching contexts and so on I would be VERY surprised to see anyone who knows what they're talking about find this metric totally worthless in the same way that you have.
I'm an Micro-EE, and having worked on a couple of software projects with some software eng. guys I can really recognise your mindset.
There are two things that seem almost incomprehensible to them:
1. That a whole bunch of crufty redundant code in tight loop, "doesn't matter because it doesn't add to the complexity because it's constant time"
2. That ADDING an additional nested loop in place of complex state-machine type logic could possibly be more efficient... "but it's O(n^3) now instead of O(n^2)!!!"
Sure, that's a counter-intuitive example - but my thinking was not limited by their "n^3 is bad" mantra they had "learnt". I was able to easily recognise that their stupid, massive state-machine logic was way more cycle-heavy for the current problem parameters than simply replacing it with another very simple loop. It shrunk that particulary cpp file by 500 lines and resulted in about a 6x speedup for that section of code.
Was my solution going to be 6x faster for all possible data sets? No, in fact it would have been much SLOWER given large data sets but the problem paramters were clearly defined (not to mention we were already taking worst-possible-case data due to limitations of other parts that were beyond our control).
COUNT THE CYCLES. Do the maths. Big-O is a useful TOOL but most people seem to be completely missing its point.
You can NOT just throw those CONSTANTS away and forget about them. At some point, you have to plug in those co-efficients, because you may be surprised to learn that the O(n^3) solution works quicker than the O(n^2).
there is no partitioning of memory to "kernelspace" and "userspace"
Yes, there is. Try some kerneltrap articles to learn more about Linux (and OS internals in general:-). This article describes how systems with > 1GiB "big memory" works on Linux on ia32, which is reminiscent of the himem.sys days of MS-DOS;).
2^32 = 4 "GiB". That's all you can address with 32 bits.
On ia32, Linux allocates 1GiB of virtual address space to the kernel, and the remaining 3GiB to user space.
Thus, the maximum amount of physical memory that can be mapped to a stock ia32 kernel is 1GiB.
This is enabled via the PAE (Physical Address Extension) extension
of the PentiumPro processors. PAE addresses the 4 GB physical memory limitation and is seen as Intel's answer to AMD 64-bit and AMD x86-64. PAE allows processors to access physical memory up to 64 GB (36 bits of address bus). However, since the virtual address space is just 32 bits wide, each process can't grow beyond 4 GB. The mechanism used to access memory from 4 GB to 64 GB is essentially the same as that of accessing the 1 GB - 4 GB RAM via the HIGHMEM solution discussed above.
There are awkward things you can do at kernel compile-time to get more than 1GiB accessible to the kernel on ia32, but it's not as pretty as you seem to be thinking.
I'm sure you're right in your skepticism that "people" won't be buying it. And that's because it's not for "people", it's for datacentres. A place where $250 would barely even pay for a weeks (days?) worth of electricity. You're talking about places that have an annual turnover that is well into the 7 figures, at least.
The standard is used as common ground for reference and comparison. It doesn't just outline specs, but justifies them too. So they can look to this document to see how they may improve.
And as for being audited for not paying for a "standard" for which you haven't paid for and have accidentally implemented on your own, this is irrelevant. You can use the contents of just about any standard I know of to your heart's content, this includes USB, Bluetooth, and MIDI - sure, you need to pay for the full spec - but if you build your work around an "abridged" or alternative version of the spec, nobody is going to care.
They only care when you say "My device is Bluetooth!", even in that case you have to do much more than buy the spec (big $$$ on having a testing facility evaluate your "bluetooth" device's implementation so you can get that cool little blue logo on it).
I think the only reason these guys would be upset if you accidentally came up with a datacentre that looked like the one(s) in their spec would be.... actually, I have no idea. I doubt they'd care one jot.
there is nothing available, at all, regarding MOS circuitry.
Interesting... perhaps due to having multiple CMOS/VLSI specialists as lecturers, MOS and low-level semiconductor theory and applications had a significant presence.
And from what you would describe it sounds like they're missing out on one of my favourite experiments, which was turning a CRO into a black&white television... lots of fun with PLLs etc. (it's hard to say which subjects are purely digital and which are analogue - that same subject had us modulating binary data over the wire and air in BPSK/QPSK etc. and analysing performance experimentally). Here is the degree I'm doing.
Zilch in signal propogation. I find this odd, the justification for teaching the "Computer Systems" stream this stuff (along with the electro-magnetic physics and maths subjects, and Finite Element Model analysis) was that high-speed digital circuitry would need careful consideration of transmission line effects.
I hate to break the news to you, but that background you have in "computer systems" puts you ahead of about 999 out of a thousand working electrical engineers as an analog wonk.
I don't know what to say... perhaps I should hold my University in higher regard than I do, or maybe the American Universites are aimed at being more vocational than academic as many have suggested.
Then again, perhaps my Unviersity is just old fashioned; Verilog content was only introduced this year for bachelor students...
I think you're taking a fairly simplistic view of current EE teaching in general. I know that in my course, of the 8 subjects offered in first year, only one is purely digital.
I'm in 4th year now. Final semester. And this is the first semester where I can truly say it's all digital; this being the case for the stream I chose (computer systems). The alternative stream is communications (more RF/wireless stuff). This semester is all advanced DSP and CPU design, with digital control theory thrown in too.
It's not like we spend four years learning how to count in binary. But the truth is, there is a lot of demand for digital electronics, and so a lot of the curriculum has replaced the more archaic, "voodo" analog tricks with it.
That said, we still learn all about simple BJT amplifiers, with temperature stabalising modifications and all that jazz, all about their structure at an electron level (having semiconductor experts as lecturers help here), not to mention the oodles of op-amp, transmission line, passive filter theory and labs...
I even had the pleasure of designing, building and testing a microwave signal amplifier that operated at 1GHz, which I would like to think is something worth mentioning considering my stream is supposed to be "computer" specialised.
I'm a little surprised you think there are EEs out there who belive it's all just "1s and 0s"... I don't think there's a serious professional digital electronics designer out there who is that naive..
As other replies have aluded to, there's a difference between CPU time and wall time.
$ man 3 clock
clock - determine processor time used
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include
clock_t
clock(void);
DESCRIPTION
The clock() function determines the amount of processor time used since the invocation of the calling process, measured in CLOCKS_PER_SECs of a second.
So as you can see, even if they used this standard POSIX function to measure time it'd still be counting clock cycles, just measured in hours.
top(1) and ps(1) can also tell you the amount of CPU time (measured by cycles spent on the process but reported in units of TIME) a certain process has taken up since starting.
For instance, I've been running Firefox for about 3 hours now, but it's only used about 11 minutes (10:59.39 minutes exactly) of CPU time (in the 2nd-last column of the ps list):
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND csirac 7377 2.3 19.3 296996 151956 ?? S 5:51AM 10:59.39/Applications/Net/Firefox.app/Contents/MacOS/firef ox-bin
It's an OK IDE. I dislike the bracket chasing immensely.
What I hate. Absolutely, brain haemorrhagingly hate - is its tendancy to somehow corrupt my.vcproj files such that the debugger doesn't work. At all. Ever.
It comes up: "Microsoft Development Enviornment: Unable to attach to machine."
How do I know it's a problem with the.vcproj file? Because deleting it, recreating the project, re-adding all the files "cures" the problem. For a while. Also, this "cancer" only affects certain projects at any one time until I re-create the project files. Other projects will enter debugging just fine.
I have spent _HOURS_ trying to fix this problem. When I really should be refactoring some crusty C++ code, instead I'm trying to get this bastard bullshit debugger to work. The most information I could find on the 'net, was some problem with version conflicts with the MS.NET framework, there was a random post on some forum with instructions to create a crazy XML config file in the same directory as some random.exe file but the only occurance of this file I had was in MS Office Program Files...
I tried, I really tried to use MS VC, and I understand that surely I am one of only a very few people in the whole world that have this problem. It was the same story on other PCs at my work, but they all use the same Corporate Image so who knows where the problem actually lies.
My solution was to install cygwin and create a set of Makefiles for GCC and use gdb for debugging, MS VC 7.1 for the final release builds.
What is the point of this post? I wish I had this book handy when I was going through this. There was absolutely _NO FRAPPING CLUE_ as to how I could have possibly fixed my problem. Nothing in any event log, I even pored over sysinternal's "filemon" real-time trace logs to get a clue as to what was happening (or not)... but I was totally lost.
Now I know how diehard windows geeks feel trying to get any work done on Linux...
Do you know of any way I could export.svg to a bitmap format without anti-aliasing?
Perhaps with the improved gradient support, a.eps export is now feasible for my purposes... and could then be rasterised into.png without the antialiasing by some 3rd-party program, like convert.
SVG is an XML format. You can describe arbitrary shapes using basic polylines, circles, squares, etc. and animate it too - all using XML. It's a W3C standard. You can even use CSS for your vector graphics!
I've been working on a very complex piece of software that does some work vectorising bitmaps. It has a non-standard (but basic) intermediate file format that I needed to visualise in a hurry.
By using Perl and installing the SVG lib from CPAN, I was able to write a program in just 3 hours that parsed this app's crazy intermediate line-vector files and turn it into industry standard SVG files that can be viewed with a web browser, or with Inkscape.
Because every element (every line, piece of text, circle, etc.) has an object ID, and being XML you can mash your own custom properties onto things, I found Inkscape very useful for not only visualising these files but exploring other non-visual things I was able to mangle into the line segments (open.svg file in Inkscape, right-click, go look at "object properties").
SVG and Inkscape have been invaluable for exploring how my refactoring of this application has affected the output...
There was just one problem: For a program that uses.svg natively, it sure as hell depended on bitmap formats for exporting to alternative formats properly... I see now that postscript and.eps support has been enhanced, hopefully the transparency/gradient stuff won't bork the output too much now.
Also, I still cannot find a way to export.SVG files to a rasterised image format such as.PNG without the lines being anti-aliased - I've even tried the "crisp lines" properties in the.xml file, and Imagemagick's "convert" program with the "-antialias" switch, but nothing seems to work... all the output is always antialiased... any ideas?
I realise (now) you were replying to an offtopic post... as I said elsewhere, I'm a retard.
The context I didn't realise your post was relating to was government stuff. Large NUMA/SSI/cluster setups. To which your sentiments are mostly justified.
However, I don't know about you, but I'm only doing less than 1000 lines of C++ refactored into ISO-C on my current project (long story). All the SLOC in apps that are used on a server... would number in the hojillions.
An admin simply doesn't have the time or patience to "audit" the source for the apps used in his/her own site. Much less understand the code they are looking at to be able to even begin auditing it.
How good are you at reading other's code? How well is all this userland code written?
Much less correct it, compile it, test/manage defect regressions, test and deploy modified versions. And commit the changes back. If an admin can do all this, what are they doing in an admin job? 99% of admins use off-the-shelf software, the most they might modify their apps is perhaps applying patches to source. Their programming is mostly in Perl/Python/Ruby/Bash/sh scripts.
Yes, you *could* find user-land OpenBSD patches and back-port them to a rusty Linux distro, but then your security can only at best match OpenBSD's.
Who is going to set up a team to audit code in a Linux distro? Who is going to decide *WHAT* to audit? Most distros are too diverse, OpenBSD gives you a very finite set of userland apps that have been audited... and it's the only feasible way, given their resources and the level of quality they commit to apps that they do look after.
When we start talking about "we could audit the Linux code instead", well we could in fact just take the Linux 2.2 kernel and patch it up to work with AMD64 couldn't we... but people don't because we have Linux 2.6.
I will admit most servers don't "need" OpenBSD-like security, but I'm sure you'll agree that most small to mid sized businesses where OSS usage is booming also don't need 128-way SMP boxen.
Perhaps the businesses I've looked after were too small, and tell the truth I've only ever used Linux for internal stuff (now looking into OpenBSD for some sites that want web exposure)... but even a basic "server" hardware package for sub-20 workstation sites spends a lot of time idling...
Anyway, it's late... I need to learn more OpenBSD...
Ugh... "without a journalling file system, the super-reliability needs might not be met."
IIRC, there was a lot of discussion about OpenBSD's filesystem a while back.
Moral of the story: OpenBSD's scheme *guarantees* reliability, data integrity at ALL times, whereas journalled ext3 doesn't (or something)....
You've missed the whole point of OpenBSD... 1) It's code is obsessively analysed for flaws, and is made to be absolutely as correct as possible 2) As a result of this, it is RELIABLE 3) As a result of this, it is SECURE
Something which cannot be said of most Linux distros, not to the same degree of consistent quality.
It's all about choosing the right tool for the job. Forgive my arrogance if my assumption here is wrong, but from this: " and there you can just port fixes from OpenBSD"... it seems you don't have much experience or knowledge with OpenBSD or the "server scene" at all.
Re-reading my reference they're basing their stats from 125 countries (pop. > 1M), not saying there are now 125.. all I could get out of it was a prediction of around ~30 countries by 2025.
Here is some leftist scare-mongering "propaganda" about the population vs arable land scarcity documentation, but it does seem to have a list of credible references and appears to be written by a sane organisation/peoples.
Here's some juicy bits:
The combination of FAO data on arable land with UN population estimates for 125 countries with populations of more than 1 million illustrates the decline in per capita arable land between 1960 and 1990. Incorporating UN medium population projections for 2025 suggests an even more rapid decline over the next 30 years, and the acceleration is projected to continue through at least the middle of the next century. The decline can be seen more clearly through the lens of the scarcity benchmark....
Until now, arable land scarcity has not been much of a problem. Four countries were experiencing arable land scarcity in the early 1960s: Kuwait, Singapore, Oman and Japan.
Now it's more than 125, with more to come.
I actually come from a farming family. I'm an Australian. We were forced off our farm in the 80s. Google for "salinity", perhaps "pyramid salt" , a government scheme where they turned a previously productive farming area that become a wasteland due to rising watertables, into a fucking SALT MINE. If that doesn't scare the living shit out of you, then you're a moron. As an Australian who lives in one of those "big wide open spaces just waiting to be farmed", I invite you to just try and come here and try and grow any crop at all anywhere in the least-arable half of Australia's land mass. You will find a significant proportion of Australia will not even let you grow so much as a blade of grass.
I am by no means a "greeny leftist", god forbid they actually they actually have the "foresight" to protest about something I actually care about (which would in effect trivialise the issue "oh look, protesters, it must be pointless").
Jesus christwagons. I cannot believe your utter blissfull, utopian ignorance of the shrinking amounts of fertile farmland on this earth. You justify our hilariously unsustainable resource consumption on the premise that Star Trek writers are going to invent an actual protein resequencer?. You've really made me so angry; I've used bold type like 5 times now!! ARRGH!
OPEN LAND IS NOT EQUAL TO FOOD. There are in fact VERY FEW areas in the countries that you mention that are good for farming, for christ's sake. China? It's rapdily turning into a desert. 1.5 million square kilometers is classified as desert, growing at a rate of 1000 sq. km per year. They physically do not have enough farmland to feed themselves and are importing more and more significant amounts of their staple foods just to live.
God... I can't believe you could be so BLIND... just travel somewhere, OK? Have you ever even seen a desert? Or even a farm, in your own country? At all? Christ... imagine trying to grow sorghum in Sibria... I'm going to be angry for hours...
Slashdot Mirror
and until it is linux will stay with >1% marketshare.
Good, as long as it doesn't go below 1% then...
You call them "British misspellings", others would speak of "American misspellings".
;-)
Personally I think it's a dozen of one and twelve of the other
I disagree. I spent a lot of time in Eastern Europe, and the young people overwhelmingly tell me that it's American English their teachers want them to learn.
:-) It's amazing how easily we absorb habits from others...
I don't claim to be well read, travelled or wise - but foreign exchange students I've talked to over the years at university from western europe seem to indicate a preference for British english... although to tell the truth, for the ones that weren't good at it, the only thing "british" about their english was spelling.
My sample space may be insufficient to make a properly informed conclusion, but that's the impression I got from friends who were from France, Italy, and Sweden - not to mention the slew of other nationalities from asia and africa. Many mention that both US and British spellings are accepted. Those that seemed to use American spellings exclusively seemed to be Japanese, and perhaps Korean/Chinese (I didn't get to know any well enough to learn their habits).
Interestingly, one exchange student that very much avoided American spelling even more than I do was from India - I edited his thesis for him. He seemed to have his own brand of sentence structure... and using 3rd person seemed a challenge for him. After 70 pages it was starting to wear off on me too
Either way, Americanisms are definately taking over our culture here in Australia; I know the way that myself and my peers speak and write is quite different to that of my grandparents (early 70s).
My little brother (13) and his friends seem to be almost completely americanised - it's amusing to make fun of their "Dragon Ball Zed". And I suspect their spelling habits come from not bothering to change the default spell-check options in MS Word. But most amusing of all, is the adoption of various mannerisms they learn from movies and pop culture. "I'll cut you", "Bring it on, biatch", and so on. All whilst wearing an Eminem t-shirt (whom I detest)...
I hate to break it to you, but that's a lazy Americanism.
I'll have to take your word for it being unique to America... if I was trying to write with a more formal tone, I'd use "I have never left Australia".
To me, "never" is less ambiguous than "haven't" because "haven't" is open to being interpreted differently if the sentence is taken out of context.
All that aside, Australians speaking informally aren't exactly known for their disciplined use of language. My "less educated" (more likely, less anal) friends hate it when I correct them on improper verb tenses, E.G. "seen" instead of "saw" (E.G. "I seen it" instead of "I saw it"), "done" instead of "did" (E.G.: "I done it" instead of "I did it"), and so on.
I agree about there possibly being an evolution of a "standardised" usage of english (a set of common , boring vocabulary without too much redundancy) by non-english speaking nations doing business with each other, but in my experience it does not seem to be based on American english.
Granted, I haven't had that much experience (I've never even left Australia), but the foreign exchange students I know have all used British conventions, not American. This would include persons from: Italy, Ukrain, Germany, Finland, France, various nationalities from Africa (Zimbabwe, Nigeria, South Africa), Singapore, Hong Kong, and India.
In fact, about the only nationality I have encountered using American English are Americans, Canadians and Japanese. I do have some acquaintences from China and South Korea but I can't remember any of their written english habits... I suspect they use American english too; but it seemed the Chinese guy I knew had learnt all his english from programming and Operating Systems.
As I already posted, the X2100 is single-CPU.
What I would really like to see is a v20z with a SATA instead of SCSI option. These are supposed to be cheap servers, and if SATA drives are good enough for their FC SAN storage products, why aren't they good enough for servers?
SAS might as well be SCSI in my situation... it's still not cheap, plentiful SATA.
I don't remember complaining about cheap stuff breaking, either: I understand the benefits of "real" hardware but cannot afford it. As such, what I'm putting together avoids relying on any one server.
But if you ask me, cheap reliable storage with commodity HDDz is a solved problem. My setups so far have used RAID-1 with 1 or 2 hot spares - I haven't bothered with RAID-5 yet.
I'm only dealing with about 6-8U worth of stuff in each rack at each site, not exactly datacentre proportions... as long as each RAID array can handle a failed disk for at least 1-2 weeks I'm good.
I'm aware of this model, however it is only single-CPU and has only two hot-swap drive bays. It's "2-way" in the sense that you can put a single dual-core AMD 27x CPU in it...
What I would really like, is the v20z with SATA instead of SCSI. Then I'd be a bit happier, except the system I'm looking at building myself is a 3U rack with 8x hot-swap SATA bays.
It seems they don't like the idea of having your app server also hosting mass storage.
It seems they would rather you bought separate FC SAN storage for your data storage (the FC "storage solutions" they promote use SATA) and kept your servers running on SCSI in a different box. Which would make sense in an idea world, but it doubles my startup cost..
I'm pricing 2U & 3U rack-mount servers to run Linux.
:(
My desired system is a dual 27x Opteron with 4-6 hot-swap SATA drive bays. What's with all the SCSI out there? There doesn't seem to be any brand-name dual-CPU rack servers out there which have a SATA option.
Yes, I know SCSI is much faster, has a fraction of the CPU overhead that PATA has, and has been hot-swap capable since probably before I learnt how to read.
Perhaps I'm trying to stretch my budget too thin, but the best I can do is build my own from components using 3Ware SATA RAID.
In my limited experience with SCSI, I've actually seen two occasions where having all the disks on the one channel was a bad idea. In both cases, a faild disk managed to lock the entire bus so that none of the good disks could be accessed - rendering the live running failure tolerance of RAID useless.
So, the idea of cheap SATA drives with their independant connections to the RAID adpater appeals to me.... but this doesn't seem to be an option on any of the brand-names
I forgot to mention each IEC mains cable and each power point on the main repair bench was powered through a "lifeguard" personal mains power safety box. Thing. Although the earth-leakage detection on most modern mains circuits installed into your building will cause a trip at a certain threshold current on their own, these "personal" mains safety boxes (usually aimed at tradesmen with power-tools at a building site, I think) are designed to have a much lower threshold current and hence the theory is, that in some cases, it should prevent you from being zapped as bad (or as long) as you would just depending on the mains breaker for the entire circuit in that room.
:-)
As for tooling: forgot to mention... we had another keyboard tray that was stowed conveniently under the new systems bench with cable test gear, mod connectors, and crimping tools along with some boxes of Cat-5e overhead on a shelf for quickly making cables on demand.
The rest of our tools were pretty basic... a few nifty magnetic gadgets and tweezers for removing lost screws in the bowels of some $5,000 printer, a few multimetres, we also had some specialised stuff for troubleshooting some customer sites that used RS485 multi-drop networks, a whole assortment of adapters and cables... but nothing that stands out except: known working common computer bits for when you need a sanity check
If you ask me, the worst part was getting the other techs to keep the tool kits clean, vaguely sorted and free of junk... I don't know how many times I had to go outside and hunt for needle-nose pliers or cripming tool in on the floor of one of the work vehicles!
On the rare occasions that you need them, some driver kits with the "weird" ends suitable for compaq, "security", and hex screws are extremely useful... keep in a safe place!
The workshop was compact but the main repair bench had 12 "stations", 6 stations on each side opposite each other. They had keyboard trays underneath them, and all cables (IEC mains, RJ45 LAN, telephone, VGA, keyboard) came up from the bottom through a hole about 50cm inward in a bundle for each station.
;), etc).
This main bench was about 5 metres long.
Running down the middle of the table from end to the other was a narrow shelf raised up about 30cm above the work area. It was actually a "double" shelf, a second sheet of MBF was raised another 5cm above the first. This 5cm gap held most of the power cabling and LCD PSUs.
On top of the raised shelf sat 8x 15" LCDs - 6 down one side, and 2 on the opposite. One side was meant to be dedicated to desktop PCs, the other for laser printers and big 'ol servers.
Our "stuff storage" was actually under the table, assorted into 50cm squar(ish) plastic bins.
On a wall on the side of the bench that had the 6x LCDs, were the "in benches", which ran as long as the main bench. A whole wall with 4 levels of shelving. That was quite full a lot of the time... the out shelves were even bigger.
The main bench was not against any walls of the room, so you could all the way around it but both ends of the main repair bench had a "wall" capping them off extending from the floor to the roof that we hung stuff off of (USB ethernet dongles, 2.5" IDE adapters, useful CDROMs (Knoppix
Standing at the PC-repair side, the right-hand wall thing had yet another bench with a "station" - another 15" LCD, keyboard tray, LAN, etc. with a KVM that switched between four "wall-mounted" motherboards (fully functioning PCs - just with their bits screwed to the wall). These were used for testing faulty HDDs, antivirus scanning, data recovery, etc.
There was another workbench dedicated to building and configuring PCs, but it only had one 15" LCD, keyboard tray, etc. on a KVM that could switch between four different PCs being "run up" from new. It was kind of cramped and only useful for doing the software side of things... actually building PCs ended up being done on the main repair bench anyway, but at a pinch these were used when room was scarce and the situation urgent.
We also had compactuses, marvellous space efficient storage devices - shelves on tracks that can all slide up against each other or expended wherever you need to walk in and get something. These were used to hold components and cards and seldom-used things.
We had a POST probe, but it was only really useful for writing something intelligent on an RA form for faulty motherboards - by the time you're pulling out a POST probe, chances are that knowing the BIOS halts at "DRAM cache init fail" is not going to help you make a physical repair to the motherboard...
A word about the LAN at each repair station: We had cabling running to a linux box using a bunch of D-Link 4-port ethernet cards. I think we had a total of 14 10/100 ports on that thing. We set up each of the 8 repair bays that had an LCD and LAN on the main bench with its own subnet, and configured the firewall rules with fwbuilder. It worked great. I even set up transparent proxy caching with squid; although I had to create specific rules to allow the Microsoft Windows Updates to actually use the cache.
Why did we firewall each repair bay individually to its own little subnet? Because we didn't want customer's PCs infecting each other with worms... I tried running snort and mrtd with the server's screen set to tail -f the appropriate logs but found if there actually was worm activity going crazy on 2 or 3 stations, it ate up all the RAM and CPU and things would crawl to a halt.
Other LAN segments:
- one with the 4x wall mounted PCs and a couple of file servers
- one that had the 4x "new systems" bench stations and a couple of ports to our training room that was used for software trainings to our customers
- one that contained PCs related to the running of the business (POS, j
Hey, don't get me wrong. I have no idea why I would want any email in an SQL database either. As was pointed out, a filesystem storage scheme suites email perfectly.
;)
I'm developing an app that involves image archiving. The SQL DB contains image IDs which translate to files on a JFS filesystem that hold the actual (1MiB or so) images.
There's a time and place for everything... perhaps I'd put email in an SQL DB if I was adding plenty of searchable meta information to each message for statistical analysis and stuff...
Was just trying to be informative
Doing a trace on a DB for a simple query tells you absolutely nothing about its scalability.
How remarkable these algorithms guys are. The thing about SCALING in this scenario is all about the ABSOLUTE terms of the physical implementation.
It's sometimes known as 'DIMENSIONING'.
WHY IS IT SO IMPOSSIBLE FOR SOFTWARE ENGINEERS TO UNDERSTAND THE CONCEPT OF "COUNTING CYCLES"?
If you find that 100 syscalls are being made per DB query and only 10 per FS query, that tells you quite a lot. It means that the FS implementation is using 1/10th the number of syscalls to get the same amount of work done for this particular scenario.
Does that prove in any way it's going to be 10x more efficient in every scenario based on this test alone? NO, but considering the expense of switching contexts and so on I would be VERY surprised to see anyone who knows what they're talking about find this metric totally worthless in the same way that you have.
I'm an Micro-EE, and having worked on a couple of software projects with some software eng. guys I can really recognise your mindset.
There are two things that seem almost incomprehensible to them:
1. That a whole bunch of crufty redundant code in tight loop, "doesn't matter because it doesn't add to the complexity because it's constant time"
2. That ADDING an additional nested loop in place of complex state-machine type logic could possibly be more efficient... "but it's O(n^3) now instead of O(n^2)!!!"
Sure, that's a counter-intuitive example - but my thinking was not limited by their "n^3 is bad" mantra they had "learnt". I was able to easily recognise that their stupid, massive state-machine logic was way more cycle-heavy for the current problem parameters than simply replacing it with another very simple loop. It shrunk that particulary cpp file by 500 lines and resulted in about a 6x speedup for that section of code.
Was my solution going to be 6x faster for all possible data sets? No, in fact it would have been much SLOWER given large data sets but the problem paramters were clearly defined (not to mention we were already taking worst-possible-case data due to limitations of other parts that were beyond our control).
COUNT THE CYCLES. Do the maths. Big-O is a useful TOOL but most people seem to be completely missing its point.
You can NOT just throw those CONSTANTS away and forget about them. At some point, you have to plug in those co-efficients, because you may be surprised to learn that the O(n^3) solution works quicker than the O(n^2).
Yes, there is. Try some kerneltrap articles to learn more about Linux (and OS internals in general
2^32 = 4 "GiB". That's all you can address with 32 bits.
On ia32, Linux allocates 1GiB of virtual address space to the kernel, and the remaining 3GiB to user space.
Thus, the maximum amount of physical memory that can be mapped to a stock ia32 kernel is 1GiB.
There are awkward things you can do at kernel compile-time to get more than 1GiB accessible to the kernel on ia32, but it's not as pretty as you seem to be thinking.
I'm sure you're right in your skepticism that "people" won't be buying it. And that's because it's not for "people", it's for datacentres. A place where $250 would barely even pay for a weeks (days?) worth of electricity. You're talking about places that have an annual turnover that is well into the 7 figures, at least.
The standard is used as common ground for reference and comparison. It doesn't just outline specs, but justifies them too. So they can look to this document to see how they may improve.
And as for being audited for not paying for a "standard" for which you haven't paid for and have accidentally implemented on your own, this is irrelevant. You can use the contents of just about any standard I know of to your heart's content, this includes USB, Bluetooth, and MIDI - sure, you need to pay for the full spec - but if you build your work around an "abridged" or alternative version of the spec, nobody is going to care.
They only care when you say "My device is Bluetooth!", even in that case you have to do much more than buy the spec (big $$$ on having a testing facility evaluate your "bluetooth" device's implementation so you can get that cool little blue logo on it).
I think the only reason these guys would be upset if you accidentally came up with a datacentre that looked like the one(s) in their spec would be.... actually, I have no idea. I doubt they'd care one jot.
there is nothing available, at all, regarding MOS circuitry.
Interesting... perhaps due to having multiple CMOS/VLSI specialists as lecturers, MOS and low-level semiconductor theory and applications had a significant presence.
And from what you would describe it sounds like they're missing out on one of my favourite experiments, which was turning a CRO into a black&white television... lots of fun with PLLs etc. (it's hard to say which subjects are purely digital and which are analogue - that same subject had us modulating binary data over the wire and air in BPSK/QPSK etc. and analysing performance experimentally). Here is the degree I'm doing.
Zilch in signal propogation.
I find this odd, the justification for teaching the "Computer Systems" stream this stuff (along with the electro-magnetic physics and maths subjects, and Finite Element Model analysis) was that high-speed digital circuitry would need careful consideration of transmission line effects.
I hate to break the news to you, but that background you have in "computer systems" puts you ahead of about 999 out of a thousand working electrical engineers as an analog wonk.
I don't know what to say... perhaps I should hold my University in higher regard than I do, or maybe the American Universites are aimed at being more vocational than academic as many have suggested.
Then again, perhaps my Unviersity is just old fashioned; Verilog content was only introduced this year for bachelor students...
I think you're taking a fairly simplistic view of current EE teaching in general. I know that in my course, of the 8 subjects offered in first year, only one is purely digital.
I'm in 4th year now. Final semester. And this is the first semester where I can truly say it's all digital; this being the case for the stream I chose (computer systems). The alternative stream is communications (more RF/wireless stuff). This semester is all advanced DSP and CPU design, with digital control theory thrown in too.
It's not like we spend four years learning how to count in binary. But the truth is, there is a lot of demand for digital electronics, and so a lot of the curriculum has replaced the more archaic, "voodo" analog tricks with it.
That said, we still learn all about simple BJT amplifiers, with temperature stabalising modifications and all that jazz, all about their structure at an electron level (having semiconductor experts as lecturers help here), not to mention the oodles of op-amp, transmission line, passive filter theory and labs...
I even had the pleasure of designing, building and testing a microwave signal amplifier that operated at 1GHz, which I would like to think is something worth mentioning considering my stream is supposed to be "computer" specialised.
I'm a little surprised you think there are EEs out there who belive it's all just "1s and 0s"... I don't think there's a serious professional digital electronics designer out there who is that naive..
Anyway, I'm off to do more FPGA work...
As other replies have aluded to, there's a difference between CPU time and wall time.
/Applications/Net/Firefox.app/Contents/MacOS/firef ox-bin
$ man 3 clock
clock - determine processor time used
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include
clock_t
clock(void);
DESCRIPTION
The clock() function determines the amount of processor time used since the invocation of the calling process, measured in CLOCKS_PER_SECs of a second.
So as you can see, even if they used this standard POSIX function to measure time it'd still be counting clock cycles, just measured in hours.
top(1) and ps(1) can also tell you the amount of CPU time (measured by cycles spent on the process but reported in units of TIME) a certain process has taken up since starting.
For instance, I've been running Firefox for about 3 hours now, but it's only used about 11 minutes (10:59.39 minutes exactly) of CPU time (in the 2nd-last column of the ps list):
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
csirac 7377 2.3 19.3 296996 151956 ?? S 5:51AM 10:59.39
It's an OK IDE. I dislike the bracket chasing immensely.
.vcproj files such that the debugger doesn't work. At all. Ever.
."
.vcproj file? Because deleting it, recreating the project, re-adding all the files "cures" the problem. For a while. Also, this "cancer" only affects certain projects at any one time until I re-create the project files. Other projects will enter debugging just fine.
.NET framework, there was a random post on some forum with instructions to create a crazy XML config file in the same directory as some random .exe file but the only occurance of this file I had was in MS Office Program Files...
What I hate. Absolutely, brain haemorrhagingly hate - is its tendancy to somehow corrupt my
It comes up: "Microsoft Development Enviornment: Unable to attach to machine
How do I know it's a problem with the
I have spent _HOURS_ trying to fix this problem. When I really should be refactoring some crusty C++ code, instead I'm trying to get this bastard bullshit debugger to work. The most information I could find on the 'net, was some problem with version conflicts with the MS
I tried, I really tried to use MS VC, and I understand that surely I am one of only a very few people in the whole world that have this problem. It was the same story on other PCs at my work, but they all use the same Corporate Image so who knows where the problem actually lies.
My solution was to install cygwin and create a set of Makefiles for GCC and use gdb for debugging, MS VC 7.1 for the final release builds.
What is the point of this post? I wish I had this book handy when I was going through this. There was absolutely _NO FRAPPING CLUE_ as to how I could have possibly fixed my problem. Nothing in any event log, I even pored over sysinternal's "filemon" real-time trace logs to get a clue as to what was happening (or not)... but I was totally lost.
Now I know how diehard windows geeks feel trying to get any work done on Linux...
Do you know of any way I could export .svg to a bitmap format without anti-aliasing?
.eps export is now feasible for my purposes... and could then be rasterised into .png without the antialiasing by some 3rd-party program, like convert.
Perhaps with the improved gradient support, a
Inkscape is utterly fantastic, so is SVG.
.svg file in Inkscape, right-click, go look at "object properties").
.svg natively, it sure as hell depended on bitmap formats for exporting to alternative formats properly... I see now that postscript and .eps support has been enhanced, hopefully the transparency/gradient stuff won't bork the output too much now.
.SVG files to a rasterised image format such as .PNG without the lines being anti-aliased - I've even tried the "crisp lines" properties in the .xml file, and Imagemagick's "convert" program with the "-antialias" switch, but nothing seems to work... all the output is always antialiased... any ideas?
SVG is an XML format. You can describe arbitrary shapes using basic polylines, circles, squares, etc. and animate it too - all using XML. It's a W3C standard. You can even use CSS for your vector graphics!
I've been working on a very complex piece of software that does some work vectorising bitmaps. It has a non-standard (but basic) intermediate file format that I needed to visualise in a hurry.
By using Perl and installing the SVG lib from CPAN, I was able to write a program in just 3 hours that parsed this app's crazy intermediate line-vector files and turn it into industry standard SVG files that can be viewed with a web browser, or with Inkscape.
Because every element (every line, piece of text, circle, etc.) has an object ID, and being XML you can mash your own custom properties onto things, I found Inkscape very useful for not only visualising these files but exploring other non-visual things I was able to mangle into the line segments (open
SVG and Inkscape have been invaluable for exploring how my refactoring of this application has affected the output...
There was just one problem: For a program that uses
Also, I still cannot find a way to export
I realise (now) you were replying to an offtopic post... as I said elsewhere, I'm a retard.
The context I didn't realise your post was relating to was government stuff. Large NUMA/SSI/cluster setups. To which your sentiments are mostly justified.
However, I don't know about you, but I'm only doing less than 1000 lines of C++ refactored into ISO-C on my current project (long story). All the SLOC in apps that are used on a server... would number in the hojillions.
An admin simply doesn't have the time or patience to "audit" the source for the apps used in his/her own site. Much less understand the code they are looking at to be able to even begin auditing it.
How good are you at reading other's code? How well is all this userland code written?
Much less correct it, compile it, test/manage defect regressions, test and deploy modified versions. And commit the changes back. If an admin can do all this, what are they doing in an admin job? 99% of admins use off-the-shelf software, the most they might modify their apps is perhaps applying patches to source. Their programming is mostly in Perl/Python/Ruby/Bash/sh scripts.
Yes, you *could* find user-land OpenBSD patches and back-port them to a rusty Linux distro, but then your security can only at best match OpenBSD's.
Who is going to set up a team to audit code in a Linux distro? Who is going to decide *WHAT* to audit? Most distros are too diverse, OpenBSD gives you a very finite set of userland apps that have been audited... and it's the only feasible way, given their resources and the level of quality they commit to apps that they do look after.
When we start talking about "we could audit the Linux code instead", well we could in fact just take the Linux 2.2 kernel and patch it up to work with AMD64 couldn't we... but people don't because we have Linux 2.6.
I will admit most servers don't "need" OpenBSD-like security, but I'm sure you'll agree that most small to mid sized businesses where OSS usage is booming also don't need 128-way SMP boxen.
Perhaps the businesses I've looked after were too small, and tell the truth I've only ever used Linux for internal stuff (now looking into OpenBSD for some sites that want web exposure)... but even a basic "server" hardware package for sub-20 workstation sites spends a lot of time idling...
Anyway, it's late... I need to learn more OpenBSD...
Okay, I'm a retard... didn't see the original post you were answering to... stupid mods ;)
Ugh... "without a journalling file system, the super-reliability needs might not be met."
... it seems you don't have much experience or knowledge with OpenBSD or the "server scene" at all.
IIRC, there was a lot of discussion about OpenBSD's filesystem a while back.
Moral of the story: OpenBSD's scheme *guarantees* reliability, data integrity at ALL times, whereas journalled ext3 doesn't (or something)....
You've missed the whole point of OpenBSD...
1) It's code is obsessively analysed for flaws, and is made to be absolutely as correct as possible
2) As a result of this, it is RELIABLE
3) As a result of this, it is SECURE
Something which cannot be said of most Linux distros, not to the same degree of consistent quality.
It's all about choosing the right tool for the job. Forgive my arrogance if my assumption here is wrong, but from this: " and there you can just port fixes from OpenBSD"
Re-reading my reference they're basing their stats from 125 countries (pop. > 1M), not saying there are now 125.. all I could get out of it was a prediction of around ~30 countries by 2025.
None of the countries you listed are in the top 50 most arable countries in the world. Of the ones you did list, here are the figures: for the amount of arable land per country:
...
United States - 19.13 %
Russia - 7.33 %
Australia - 6.55%
Canada - 4.96 %
Here is some leftist scare-mongering "propaganda" about the population vs arable land scarcity documentation, but it does seem to have a list of credible references and appears to be written by a sane organisation/peoples.
Here's some juicy bits:
The combination of FAO data on arable land with UN population estimates for 125 countries with populations of more than 1 million illustrates the decline in per capita arable land between 1960 and 1990. Incorporating UN medium population projections for 2025 suggests an even more rapid decline over the next 30 years, and the acceleration is projected to continue through at least the middle of the next century. The decline can be seen more clearly through the lens of the scarcity benchmark.
Until now, arable land scarcity has not been much of a problem. Four countries were experiencing arable land scarcity in the early 1960s: Kuwait, Singapore, Oman and Japan.
Now it's more than 125, with more to come.
I actually come from a farming family. I'm an Australian. We were forced off our farm in the 80s. Google for "salinity", perhaps "pyramid salt" , a government scheme where they turned a previously productive farming area that become a wasteland due to rising watertables, into a fucking SALT MINE. If that doesn't scare the living shit out of you, then you're a moron. As an Australian who lives in one of those "big wide open spaces just waiting to be farmed", I invite you to just try and come here and try and grow any crop at all anywhere in the least-arable half of Australia's land mass. You will find a significant proportion of Australia will not even let you grow so much as a blade of grass.
I am by no means a "greeny leftist", god forbid they actually they actually have the "foresight" to protest about something I actually care about (which would in effect trivialise the issue "oh look, protesters, it must be pointless").
Jesus christwagons. I cannot believe your utter blissfull, utopian ignorance of the shrinking amounts of fertile farmland on this earth. You justify our hilariously unsustainable resource consumption on the premise that Star Trek writers are going to invent an actual protein resequencer?. You've really made me so angry; I've used bold type like 5 times now!! ARRGH!
OPEN LAND IS NOT EQUAL TO FOOD. There are in fact VERY FEW areas in the countries that you mention that are good for farming, for christ's sake. China? It's rapdily turning into a desert. 1.5 million square kilometers is classified as desert, growing at a rate of 1000 sq. km per year. They physically do not have enough farmland to feed themselves and are importing more and more significant amounts of their staple foods just to live.
God... I can't believe you could be so BLIND... just travel somewhere, OK? Have you ever even seen a desert? Or even a farm, in your own country? At all? Christ... imagine trying to grow sorghum in Sibria... I'm going to be angry for hours...