These days, they just take away grant money and observation time.
I guess it's more humane - you can still make a living writing technical books, which you can't do as a pile of ash - but it doesn't help advance science a whole lot:)
It's an application for patent. It's not a patent yet, and hopefully it won't make it through the gauntlet. That said, it could easily make it through the gaps in the system.
Don't get bogged down by the "base 30" part. Patent applications have a "preferred embodiment" or current invention part, but this is not the part you have to worry about. Patent applications, if you have a good patent lawyer, try to cover off as broad a space as possible without getting summarily struck down. Look at the claims; they're the part that other companies can run afoul of. Other parts are supporting documentation to show that yes, it is an invention (you must make mention of the device the software runs on in software patents, for example) and to preemptively strike down the examiner's questions.
So, what we have here is a patent on turning lat/long information into fixed point (trivial), then represented as base anything. It does not have to be in a URL. It does not have to be base 30.
I don't think this one should stand.
I'm wondering how many other software developers hang out on here, and what they think of software patents. I'll say, for my part, that I've never had to refer to patents to help me in my line of work in any way whatsoever. Never mind the triple-indemnity-if-you-knew clauses. If you're given a problem to solve, you cover them with assumptions to make the problem easier, standard techniques and analysis, and other peoples' components to bring up the shortfall. Patents that are broad enough to worry about rarely contain content that's helpful.
I can't foresee patents helping software developers - unless you count learning to dance in minefields... 'helpful':)
I don't even actually see Microsoft being the main worry on an ongoing basis. I see our industry being held to blackmail by IP "holding companies" who do not develop software, and thus who cannot be threatened or counterattacked in the same way as Microsoft can.
Unless something really recent has come up, the 'stem cells' to which you are referring are stem cells only for that kind of tissue. The great interest in embryonic stem cells is that they are pluripotent, i.e. able to specialize into other kinds of stem cells, then finally into cells of the target tissue.
Interestingly, though, you can't just inject pluripotent stem cells somewhere, because they will differentiate into multiple kinds of tissue ('teratomas') on the spot - they need to be coaxed into the specific kind of tissue.
One of the troubles with the existing stem cell lines is that they were grown on mouse fibroblast mats as a matter of course. Good for research, but bad for using for therapeutic use.
Point on Atkins well-taken. Lost 30 lbs off that myself:)
Actually, I see the time for using embryonic stem cells will be a relatively short chapter in the overall research effort. Research is required to figure out how they work - so that we can find out why techniques like implanting adult nuclei in eggs work on occasion, but are so hit-and-miss (mostly miss).
There are serious issues with equating redshift with velocity. Some items with significantly different redshifts may be close in space. I've looked through a number of papers myself, some of which indicate that there is an extra redshift that corresponds roughly to the type of object being looked at. Otherwise, we're left in the uncomfortable position of having younger galaxies in clusters facing away from us, and older galaxies facing towards us. Anything that points to us as occupying a special position in the universe is... somewhat suspect:)
As to what the phenomenon actually is that causes the high redshifts, I don't think we know yet.
There are serious issues with equating redshift with velocity. Some items with significantly different redshifts may be close in space. I've looked through a number of papers myself, some of which indicate that there is an extra redshift that corresponds roughly to the type of object being looked at. Otherwise, we're left in the uncomfortable position of having younger galaxies in clusters facing away from us, and older galaxies facing towards us. Anything that points to us as occupying a special position in the universe is... somewhat suspect:)
As to what the phenomenon actually is that causes the high redshifts, I don't think we know yet.
It relies on an assumption that is heretofore unquestioned: redshift is a near-direct measure of velocity. Given that, then you have an 8-12 billion year estimate. If you add in inflationary theory, some cross-checking will get you 13.7 billion years as a best guess. More recent mainstream decelerate-accelerate theories vary the estimate somewhat.
Jesus, I just had a look at that thing. I've gone through the patent rigmarole a couple of times myself (still a couple pending), and must say that this out-fluffs our fluffiest patent by an order of magnitude.
Take away the standard boilerplate for 'can be run on any kind of terminal', and the preferred embodiment taken from a diagram in a database class tutorial workbook, and you're left with practically nothing. This isn't an invention, it's an idea.
As a software developer, someone can come up with the likes of this in their head during two minutes of idle chatter. Throw a tape recorder in any shoot-the-breeze session at an operations meeting every week, and you could churn out 50+ of these things a month. That's not where the real work is. It's not like describing a catalyst process that can shave your energy costs by 20%, or discovering a 5-step process to make finasteride. They've just thrown fancy words around a business requirement.
As a software developer, I worry that I tread on hundreds if not thousands of these things, just in the process of doing completely independent business. There are certain processes that have to be done to meet a business requirement that you don't need anyone else's patent to solve:
Optimizing - if round-trip time is taking too long, you have to cache it, bring it closer - your only other alternative is to throw hardware at it. Yet, there are patents on caching. It won't be on caching itself - that would be too obvious, but apparently "caching in a data warehouse" would be a worthy patent
Interacting with users - the users will move things or type things in and scream "why won't it remember?" - there are a lot of UI patents out there, and I find it disgusting that you can take practically anything you'd do with paper, throw it on "said computing device" and it's a potentially valid patent.
Many software patents contain no useful information. The recipes on the back on food cans convey more information, and can at least lead to a practical result. If you've got the time, just start flipping through a few on the USPTO site (start at anything 6,000,000 or past it). A great many of them can be conveyed in their entirety just by their title. Try handing these to one of your development team and say "make this". Next, try hiding the patents on day 2 and see if anyone notices. They won't, because there's nothing inside them worth referring to.
I'm bitter only in that it's only good manners that are keeping idea and obvious patents from being used against the rest of us in a giant legal Whack-a-Mole game, and for the risk of being put out of business by an unscrupulous patent holder, we get precious little value from other peoples' patents. We're not licensing inventions, we're buying indemnity insurance. I wouldn't be so all up-in-arms if licensing a software patent could actually gave us even a couple of weeks' head start in a project. You're not getting any source code. If you're lucky, there are screenshots of the "preferred embodiment". Apart from that, you get a few diagrams. How many millions is that worth?
On the plus side, if you have patents, you can sell your company for more:)
I know that biotech and engineering companies try to slide by some pretty dubious patents, but even they can't hold a candle to our industry.
I do hope the headlines over this sort of thing continue. It's far too easy to go back to being complacent if things calm down again.
Still use it every day here as well. I've always found it the best compromise between speed of development, type safety, power, and ease of finding easy-to-grab components for everything from GIS to on-screen gauges to internet suites. Thumbing around Torry's or efg's Computer Lab provides a nifty, but very small, sampling of what's out there.
I'm actually pretty glad to see it's catching on again. We just attended the Delphi Diamondback/2005 roadshow, and I was impressed at the number of folks there compared to what I've seen in past years. Things are starting to pick up at the user group as well. I'll be demoing AQTime from Automated QA, a freakishly fantastic product for the price (from a corporate view, anyhow;)
I've been actually not been terribly compelled to upgrade from Delphi 5 as a development platform. Not that later versions haven't been good, but the upgrades have been mostly in areas I'm not doing anything in, like the n-tier and web pieces.
We always upgrade one copy, though, and I attend conventions as I can. When Delphi for.NET came out, I was pretty seriously impressed. They put a lot of care and attention into making sure that ports from Win32 would be as painless as possible, but to let you go off and start off with native.NET and the FCL. Took less than a week to port my framework, and most of that was learning.NET idioms (like Finalize, strings being copy-on-modify, creating weak references).
You're often at the mercy of your component vendors, though, so if you were one of those that thought that the quality of the component code didn't matter as long as it worked... the pointer-trick and copy-and-paste coder segment will fall on tough times:)
Quite frankly, porting code, the trouble spots are basically:
Third party components
String tricks (given that.NET's strings are almost over-protected, and that they are WideStrings by default
API calls
Delphi 9, or Delphi 2005, as they're calling it, is the first compelling upgrade I've seen for folks like me, who spend a lot of time in the class interface design, source code and unit testing arena.
Delphi 2005 hosts three environments, Delphi/Win32, Delphi for.NET and C#. A lot of Delphi 8's language enhancements have made it into the Delphi/Win32 side, such as enumerator syntax (for MyString in MyStringList do...). The editor, at last, does a number of the refactorings that the JBuilder crew has had access to, such as Extract Method and a smart Declare Variable (e.g. X:= MyControl.Parent will suggest TWinControl). The folding editor has a number of tricks up its sleeve, and a number of file backups are maintained which you can diff inside the environment, helpful if you run into troubles more granular than your version control system's checked-in versions. Nice to see some of the integrated tools and projects as well. New->Unit Test will give you DUnit (for Win32) or NUnit (for.NET) shells, and there are a ton more bits 'n' pieces I haven't had the opportunity to play with (the ASP.NET projects are pretty smooth).
Kylix was a bit before its time, really. Linux is such a freakishly fast-changing environment (as I sit here in my Fedora Core partition in utter awe of what yum says I must also update to update some of the major package around - gah!), and there isn't enough corporate-level interest in easy GUI programming for Linux to fund keeping up with it.
I got Kylix 2, and personally found it pretty good for porting, and a fairly decent environment (it used WINE, although apps made with it did not), although seamless it
"You CANNOT do unit testing. Think of the poor QA's who rely on our incompetence to feed their families.
*laugh*...and our carelessness to feed them dessert:)
Unit testing is great to quash some of the "ghosts in the machine" before they happen, and to make maintenance more reliable - less guesswork about whether a refactoring or other maintenance change made something screw up.
Unit testing can cover off some things that QA just can't find because they never trip off a scenario QA comes up with. Saw a line to the effect of 'if (size<0) size=-size;' in someone's code the other day - who knows what the propagation of a negative size could do behind the scenes?
Where unit testing works less well-to-rather poorly is in the interface to 'real world' pieces, like talking to your LDAP server or communicating over modem. That's the realm of functional testing, and QA goes nicely with it. With a passel of tools (such as AutomatedQA's ones, or FIT for functional testing in some environments), QA can test out user entry scenarios, installs, stress-testing, running on different hardware and using different configuration files.
Most commercial developers I know like a relatively stable environment for developing in, and would be pretty averse to setting up and tearing down different versions of a database on their machine, or constantly booting to different OS versions to check things out.
No, what's more likely to make QA folks go hungry than anything else is corporate ignorance of how important they really are, especially when QA rightly gets in the way of releasing a buggy product:)
In all seriousness, I would STRONGLY suggest unit testing.
You bet!:) It can be a major conceptual hurdle to get over (my first thoughts were along the lines of 'why would I bother going "a.b = 1; check a.b == 1" - that's stupid!', but of course that's not what unit testing is about), but it's really, really worth it.
...shouldn't they also occur every time the earth is between the pendulum and the sun...?
I've read many of the old (and new) 'push' gravity theories, the ones that theorize a particle carrier for gravity (I'll call them gravitons here). Where there are less gravitons, e.g. next to a body and more so between two bodies), you experience a lop-sided 'push' from areas of high graviton density.
With two bodies, you wouldn't be able to tell the difference - the absorption of gravitons would be measurable as though they were an appropriate pull.
Where you'd see a difference is in three bodies in a line, as the gravitons have to pass through two bodies on their way to the third, as the density (well, the flux) would already be minutely lower, hence a gravitational "shielding" effect (which would actually be more gravitational pushing from the other side).
These 'push' theories of gravity have waxed and waned in appeal over the past century or so (they're often called LeSagian theories, after Georges-Louis LeSage.) Part of the appeal is that they provide a mechanism for gravity, which GR does not truly provide (the theory of following geodesics in GR may explain paths objects take, but not why spacetime curves in that manner - what 'pulls down' on the 'fabric'?) There's a good collection of papers in Pushing Gravity which show some of the strengths and weaknesses of eight or so of the current push-gravity theories, and possible explanations of things like the anomalous in-track (and seemingly periodic) accelerations satellites can undergo.
Our theories may flip-flop a fair bit over time, but we do collect more data that needs explaining over time, and the anomalies do much more to further our understanding than the same ol'-same ol' ever did;)
It's bizarre. The universe could be teeming with life, or it could be utterly, completely barren save for us, and both alternatives would look pretty much the same to us.
Communication modes: Our communications are getting more focused, more noiselike (anyone remember what 300 bps sounded like compared to 56K compressed?), less tangible. Maybe the signal came 500 years ago. We couldn't have heard it. Couldn't have. At least the Professor on Gilligan's Island had a radio - coconuts wouldn't have worked. You can't hear radio without a radio (or finely-tuned braces). Who knows what the next physics breakthrough in modes of communication will be? Something quantum? Gravity-related? When it arrives, and if it's better, we'll switch over to it wholesale, and guaranteed we don't have receivers for it at present. Who knows what aliens would be sending their messages with?
Lucky in the life lottery: Perhaps it's easy for life to take hold on a planet, but maybe we're lucky to have had relatively complex creatures survive the multiple catastrophes. Folks sometimes theorize that Jupiter has protected us from some major calamities just by being big and in a further orbit, acting as dustbuster. Maybe life was seeded here from elsewhere. Wouldn't even have to be an organism - just a decayed crappy chunk of RNA-esque material would do for initial seeding purposes, and it would only have to happen once - one intact chunk out of millions of rocks. It took a heck of a long time to evolve multicellular organisms - the number just boggles the mind. Perhaps it's just that hard to evolve anything past single-cell organisms.
Planets: There seem to be a significant number of planets around. The program Celestia keeps a semi-current list of the detected planets and systems (so you can have fun visiting). Some of them, though, seem like there are gas giants way too big, or way too close to the sun, or are in a funny configuration. That's likely not conducive to life.
Age of the universe: I'm guessing, according to an increasing number of observations of late (mostly from the Hubble), that the universe is a lot older than we've been theorizing over the past few decades. The older it is, the more likely extraterrestrial life becomes.
The Ultimate Find: If we found someone, something out there, it would be the greatest discovery... well, practically ever. At least, "are we alone?" is something we've been asking for so long, and actually having a definitive answer would be amazing.
I think the voyages to Mars and (soon) Titan will inspire a new generation. Gads, if we can be that surprised in our own solitary back-yard...
I don't know if we'll find anything out there. I remain hopeful, but I certainly don't have "faith" in anything being out there.
The best defense against a client-side blowup is to have as many layers as possible helping out, because they all have their various strengths and vulnerabilities.
In development:
Good design: The larger the project, the more cowboy coding and migrated-to-production prototype code can hurt the process. Many bugs come in the form of workarounds, repeated code, or unclear code responsibilities, all of which can be mitigated by good design.
Unit test: Developers have a better idea of the contract the rest of a program has with various classes than any other department. Unit testing is all about proving that contract still holds, and can not only protect you against breaking that contract with other code changes, but provide a spot to add tests for newly-discovered failures (we can't necessarily account for all failures in advance). Remember: before fixing a bug, write a test that fails with the bug but should succeed, run the test and ensure it fails, THEN fix the bug.
Assert... or whatever equivalent to assertions you have that you don't turn off. So many bugs come from things that are deemed to be "impossible". If they're so "impossible", prove it. They may not be impossible in the future - most come from bad input, or changed assumptions about the code or the environment. You don't need to code in Eiffel in order to assert/complain that the input was out of range, or null, or blank, or that the lengths of two lists you're keeping in the same class should be the same. COROLLARY: If you have an assertion on bad data, you should make a unit test case with bad data, and tell the unit test case that you expect it to fail.
Reduce combinations: If you can simplify your path through the code, do it. If you have trouble tracing through the code (especially in a long method), or identical code appears throughout, extract the common pieces into something sensibly named. Many bugs crop up due to 'not remembering to update everything', or just plain not being able to keep track of the logic flow through the code in the first place, or when making changes.
QA:
Good people: Wow, does this make a difference! I thank the circumstances-that-be for our QA head Scott. Any replacement will have big shoes to fill:)
Good communication: Often, QA ends up being a liaison in many ways between support, deployers, and R&D - to ask/verify how problems happen, how things are supposed to work, and what new features and bug fixes are and imply.
Automation tools: For the tedious parts, and for regression testing. We use TestComplete for things like stress-testing, overnight testing, ensuring problems don't come up for any items in a set (good for when you have many items to load and test in any solution), and testing expectations in different environments. It also includes a slightly more white-box feature for writing test scripts that can verify exposed internal values.
Good backbone and support: QA itself needs to have the temerity to put their foot down and say "it's not ready", and it's the responsibility of others to throw their hat into the ring in support whenever this is the case, because it can be an unpopular stance. Not standing your ground on this can end up blowing up. That doesn't mean there's no ground for negotiation (e.g. we can release this to THIS specific client IF we test only for one database back-end with office-only deployment and a roll-back plan), but it's a strong starting stance.
Support and IT
Believe them: They're not making up software problems, at the very least the ones they're seeing with their own eyes. Something "impossible" just happened. It could be that there's another piece of software that munches your PDF-printing DLL, it could be a firewall setting, it cou
Also, the ability to search inside files for phrases is horribly messed. It *never* finds phrases that I know are in the files I'm searching through.
Ran into that one fairly quickly trying to search through source code files - I'm a bit disappointed at their lack of search type 'fail-over', where if it doesn't recognize an extension, it seems to do nothing, but here's a KB article on the problem.
Humans don't come out as a tabula rasa with their behavior purely economically calculated. There are some mutations and bad family lines, to be sure, but humans have a code of conduct 'wired' into them by emotions... what makes them happy, guilty, angry, etc.
Putting Asimov-style Laws into robots is perhaps inadequate. The behavior that the Laws engender should make the robots happy - then it's not just a matter of a bad Law chip to let robots run rampant, they will have learned all their lives what makes them happy, not just be a big ball of at best neutrality seething to get out.
That's assuming a decent semblance of a neural network, though, which can work well through motivation and would lead to some consistency of behavior. If, instead, it's lots and lots of procedural code that can be updated through wireless connections via Outlook, the human race as we know it would be boned.
There's a pallid yellow line jumping up from Borland Pascal Object to Delphi, which you can just barely make out crossing the snake in the background.
The missing piece that gets me is Borland Pascal Object starting from scratch in 1989 from Pascal AFNOR.
That's news to me who was working at the time, and TP 5.5 with the new object extensions came out, giving me an Object-Oriented Programming manual to pore through. It was a relatively natural extension of TP 5.0 syntax, which was already miles away (especially with its strings and units) from old UCSD Pascal.
That line should extend back to 1983 for Turbo Pascal 1.0.
As to the installer, I feel your pain. I have a number of things written in old TP, and there seemed to be something different about the installer - as though it used the CRT code calculation, but wasn't written in TP.
It did seem to be a one-time check, though, in the installer as well as in TP programs. I don't know what other modern equivalents there are to Mo'Slo,
but from what I remember trying to install it on a 333 Mhz PC (who knows if there are more issues now?), it just needs to be slowed down to old computer speeds right at the beginning of the install. Perhaps a high-priority greedy process might work in a pinch.
Do it once, put in the hacked crt.tpu files and the like, and back up the whole directory structure.
Klaus Hartnegg has an astonishing variety of fixes for the problem as well (including replacement units, ways to put the fix into CRT.ASM directly, and.exe-patching utilities), stored on his site to lessen any dead link troubles.
Man alive, all for want of an algorithm that was forward-looking enough to predict 200 Mhz machines:)
Is "somebody else patented that before you did" a valid argument in patent law?
Outside of the US, yes - it's based on first-to-file. In the US, however, it's based on a first-to-invent system. That makes it more 'fair' (you can't get completely locked out of something you invented first), but it makes for a lot more legal wrangling, and the burden of proof can be fairly hefty (just another reason to keep good R&D records).
As it stands now, your children don't end up like steadily more badly-mutated humans because there's a 'pre-culling' process that goes on. Sperm with bad mutations die or never make it very far. Eggs undergo a lesser culling process. Embryos that have problems are by and large let go naturally by the body - and mostly with good reason.
Those 'proving grounds' reset most genetic troubles from generation to generation, something that we cannot do quite as well for our own cells.
Michael West's The Immortal Cell is a pretty interesting account of one researcher who has been chasing the dream for a number of years. It's pretty fascinating reading, and those who haven't been watching the field will be amazed at what we have not only figured out, but what we have actually accomplished.
One option that comes up for the shorter term is tissue cloning. There are actually a number of things we know already (some from Michael West's book):
We actually know what telomerase (the complex that extends the telomere) is
We know how to enucleate (get the nucleus out of) eggs, put in a new nucleus, and get it to divide
The only contribution an enucleated egg makes to cell is the mitochondria
Mitochondria don't vary in their specific functionality all that much between mammalian species
This means we can actually use the eggs from other mammals
(It seems we can also 'reset' cellular programs by de-alkylating histones - those big 4-piece wintergreen mints that DNA is wrapped around. Histone alkyl 'tails' seem to have a lot to do with telling a cell what it actually does. Some of West's research indicates that you can get this to happen as part of the tissue cloning process)
So, instead of using hard-to-procure human eggs, you can perhaps use rabbit eggs (I'm sure the Australians wouldn't mind) and have what amounts to basically switching Duracell batteries for Energizer batteries. You can then pick out the healthy clonal cells for division into tissues.
With genomics, proteomics and experimentation, we can find the hormones or hormone chains to specialize the cells into skin, retinas, livers or even bone marrow.
Bone marrow gets my vote as a worthy cause. Being able to produce blood from the DNA of known-good donors would provide a decent backup if the ideal solution - cloning blood from the patient's own DNA - can't be done in time.
Sure beats any other 'stem cell source' we can get our hands on.
The next steps would be to try repairing aging cells in situ. The two biggies to fix which researchers have identified are the shortening telomeres (chromosome caps) and mitochondria (they are more susceptible to mutation, being more bacteria-like and exposed to by-products of burning food for energy).
Some good news at least in that it seems that we might not induce cancer in an attempt to lengthen telomeres - although further testing will be required.
It's pretty amazing how far we've come, but the things that are going to make the difference are going into the pipeline now - expect pretty fantastic things in 20 years, perhaps even 15.
We have a lot of observations that are pretty close to indisputable: we have spectra from other stars, we have comets visit the inner solar system periodically, there are other planets relatively close nearby. Where a lot of the flux is, is where we attempt to explain how such things got to be, or guess at the meanings or causes of things that we can't directly observe or experiment with.
It's hard to remember sometimes that the assumptions that go into a set of theories could themselves be wrong, and that the theories can support one another without ever actually proving the assumption correct.
Some of the most powerful theories are ones that survive new levels of direct experimentation. Take evolution; regardless of the furor it causes in some circles, it has survived from a period of time where nobody knew what "stuff" caused parents and children to look similar, and successive closer looks all the way up to the various Genome Projects have given it actual mechanisms and even experimental techniques.
The old Greek theory of vision resulting from ray emanations from the eye certainly wouldn't survive the advent of experimental biology, yet in its own time, it was entirely self-consistent (and raytracers behave as though it really were the case:)
It wasn't all that long ago that some theories we take for granted were still being hammered out. Take solar planetary formation. According to Gamow's One, Two, Three... Infinity, one of the major fights was between collision theory and accretion theory. Accretion theory makes so much sense to us these days - so what was the problem?
Well, back at the time, folks doing calculations determined mathematically that a planetary disk would not coalesce, but instead remain like the rings of Saturn. One way around this problem had the gaseous elements being removed by infall into the sun, but this caused profound troubles in that the sun would gain way too much angular momentum.
As it stands, the collision theory (formation from collisions between stars) ended up having more problems, and we ended up with accretion theory, with the lighter elements being blown away by solar wind/radiation pressure. The "Zodiacal Light" is assumed to be the remains of those lighter gases, but of that, we certainly can't be sure.
We can't be 100% sure of accretion theory, regardless, because we can't take perfect pictures of planetary systems in formation over millions of years. It's a good working guess, though - and as a corollary, it implies that most star systems have planets, which we seem to be finding (collision theory required a very infrequent condition, which would make planets rare).
Who knows what else out there is ready to be overturned? Gravity? (current assumption: caused by geometry) Velocity of galaxies? (current assumptions: Doppler is the cause of redshift) The Oort cloud (current assumption: there's a near-perfect sphere of comet nuclei that can be disturbed by passing stars enough to send comets our way, but not enough to distort the sphere... amongst other things;)
Some cherished scientific beliefs will be overturned in our lifetimes. (Fortunately, of course, this will not stop our electronics and entertainment from working). There's still a hell of a lot more to discover than the "we're nearing the point when we've discovered everything" crew would have us believe.
...and that should be an exciting, not a disillusioning, thought.
*laugh* The star name + letter combination will have to do for the meantime. The roman numeral convention assumes that we know all the planets in a star system, so Earth being Sol III and Mars being Sol IV is just grand for us.
For jolly gas giants around far stars, though, we don't know whether there are any other planets in orbit, or at the very least, we don't know how many other planets there are. Someone observing our system with the equivalent of our current technology wouldn't even be able to discern Jupiter or Saturn.
When we somehow (and I'd love to see how!) manage to figure out an entire remote planetary system, perhaps we'll switch back to roman numerals:)
Celestia keeps relatively up to date with discovered extrasolar planets, and it uses the star + letter convention. Obviously, though, the planet texture used when you go visit the planet is merely a guess:)
Um, they have everything to do with priority inversion. (http://www.us.design-reuse.com/articles/article24 2 5.html)
I would find it an odd design to schedule two threads of different priority on the same critical section, outside of perhaps device drivers and RTOS applications. Mutex protocols are an optional add-in to threading libraries (e.g. on AIX, here), for those instances where you would design such interaction - it's not going to happen by chance. Those interactions wouldn't be likely to happen in more than one or two "hot spots" in an application - and I would surmise those would be on the 'edges'.
Mind you, I don't know what kind of specialized software you write. It sounds like something that approaches needing realtime priority.
I have found NT to have horrible thread scheduling in a real multithreaded app.
For the priority inversion scenario, certainly. Here's an article on how NT deals with priority inversion. In practice, I've found that there's a subtle order-of-operation difference that can make a Linux/Unix-optimized approach go slower (relative to its theoretical performance) on NT, and vice versa. If I recall correctly from some of my porting efforts, NT tends to set up the new thread, continue running on the current thread, and lets the scheduler switch to the new thread later, and Linux tends to fork to the new thread immediately and lets the schedule switch to the old thread later. I was glad of the difference at one point; my thread pool suffered from a race condition I had overlooked - Linux's switching model ran into my bad assumption situation almost every time.
How is windows dealing with priority inversion in just a few instructions?
Priority inversion? Critical sections don't have anything to do with priority inversion - the operating system is free to switch thread context at any time, including right in the middle of entering or exiting the critical section.
Are you thinking about the actual OS-internal constructs that prevent task switching or interrupts, or switch "rings"? Last time I dealt with those was the SEI and CLI instructions on the old 6510 processors. The only time those types of constructs should be touched is writing device drivers, and sparingly at that:)
Actually, to tell you the truth, when I first heard about critical sections, that's what I thought they were as well, and I steered completely clear of them, thinking that a single long critical section could grind the entire computer to a halt.
>Never, ever make a call to something you don't have complete control of, or that is even remotely large, inside a critical section<
Good luck on that one:-)
In practice, it's actually not that hard to avoid. Essentially, it means avoiding constructs like this:
The idea being that process_packet is potentially long and not under your control, so if someone was to add a packet (MyPackets::AddPacket) while process_packet was going on, that thread would be blocked, and it doesn't need to be (there's nothing inherent in adding a packet that's going to affect the processing of a previous packet).
destroy_packet can be assumed to be short and totally under your control (destroying objects shouldn't be a grand affair), and if the operation is simple enough, may not need to be in a critical section at all.
Does that shed some better light on what I was saying?:)
If you actually have many threads in your program critical sections can cause really bad performance and high unpredictable latency.
That doesn't actually have to be the case. The default case for a critical section is lightning fast. I've stepped through the assembly for NT's critical section, and the non-contention path is a mere handful of instructions long, including an LOCK INC instruction, which takes about 3x as long as an INC (which is not much).
The contention path, however, involves a WaitForSingleObject call, which, while not substantial, is certainly longer, and the performance hit mostly comes from the block, not the call per se.
The critical section itself is represented by a small, basically passive structure, representing the lock count and depth count, and not a whole lot else.
There are some simple rules that can make critical sections take the non-contention path 99.99 times out of 100, and profiling results bear it out:
Contention is the performance-killer; exit the critical section as soon as the appropriate data is safe
Enter and exit the critical section multiple times if there are non-contentious lines in the middle, rather than making the critical section big
You can often work with local variables (or local copies) without critical sections, or with a critical section for the copy - performance can vary, so use your judgement
Never, ever make a call to something you don't have complete control of, or that is even remotely large, inside a critical section
Corollary: If you're sharing output, use a critical-section-protected queue rather than trying to call the output within a critical section
I've seen violations of all of the above 'rules', and heck, yeah, performance suffers:)
Critical sections can badly impact performance, but I would guarantee that the problem is their use, not the construct itself!
Other mutexes on operating systems are typically equally fast unless they're being used for inter-process communication and must be accessed/looked up by name/atom.
Slashdot Mirror
These days, they just take away grant money and observation time.
I guess it's more humane - you can still make a living writing technical books, which you can't do as a pile of ash - but it doesn't help advance science a whole lot :)
It's an application for patent. It's not a patent yet, and hopefully it won't make it through the gauntlet. That said, it could easily make it through the gaps in the system.
Don't get bogged down by the "base 30" part. Patent applications have a "preferred embodiment" or current invention part, but this is not the part you have to worry about. Patent applications, if you have a good patent lawyer, try to cover off as broad a space as possible without getting summarily struck down. Look at the claims; they're the part that other companies can run afoul of. Other parts are supporting documentation to show that yes, it is an invention (you must make mention of the device the software runs on in software patents, for example) and to preemptively strike down the examiner's questions.
So, what we have here is a patent on turning lat/long information into fixed point (trivial), then represented as base anything. It does not have to be in a URL. It does not have to be base 30.
I don't think this one should stand.
I'm wondering how many other software developers hang out on here, and what they think of software patents. I'll say, for my part, that I've never had to refer to patents to help me in my line of work in any way whatsoever. Never mind the triple-indemnity-if-you-knew clauses. If you're given a problem to solve, you cover them with assumptions to make the problem easier, standard techniques and analysis, and other peoples' components to bring up the shortfall. Patents that are broad enough to worry about rarely contain content that's helpful.
I can't foresee patents helping software developers - unless you count learning to dance in minefields... 'helpful' :)
I don't even actually see Microsoft being the main worry on an ongoing basis. I see our industry being held to blackmail by IP "holding companies" who do not develop software, and thus who cannot be threatened or counterattacked in the same way as Microsoft can.
-- Ritchie
Unless something really recent has come up, the 'stem cells' to which you are referring are stem cells only for that kind of tissue. The great interest in embryonic stem cells is that they are pluripotent, i.e. able to specialize into other kinds of stem cells, then finally into cells of the target tissue.
Interestingly, though, you can't just inject pluripotent stem cells somewhere, because they will differentiate into multiple kinds of tissue ('teratomas') on the spot - they need to be coaxed into the specific kind of tissue.
One of the troubles with the existing stem cell lines is that they were grown on mouse fibroblast mats as a matter of course. Good for research, but bad for using for therapeutic use.
I highly recommend Kiessling's Human Embryonic Stem Cells book to show the state of research as of a year and a bit ago.
Point on Atkins well-taken. Lost 30 lbs off that myself :)
Actually, I see the time for using embryonic stem cells will be a relatively short chapter in the overall research effort. Research is required to figure out how they work - so that we can find out why techniques like implanting adult nuclei in eggs work on occasion, but are so hit-and-miss (mostly miss).
-- Ritchie
There are serious issues with equating redshift with velocity. Some items with significantly different redshifts may be close in space. I've looked through a number of papers myself, some of which indicate that there is an extra redshift that corresponds roughly to the type of object being looked at. Otherwise, we're left in the uncomfortable position of having younger galaxies in clusters facing away from us, and older galaxies facing towards us. Anything that points to us as occupying a special position in the universe is... somewhat suspect :)
As to what the phenomenon actually is that causes the high redshifts, I don't think we know yet.
There are serious issues with equating redshift with velocity. Some items with significantly different redshifts may be close in space. I've looked through a number of papers myself, some of which indicate that there is an extra redshift that corresponds roughly to the type of object being looked at. Otherwise, we're left in the uncomfortable position of having younger galaxies in clusters facing away from us, and older galaxies facing towards us. Anything that points to us as occupying a special position in the universe is... somewhat suspect :)
As to what the phenomenon actually is that causes the high redshifts, I don't think we know yet.
It relies on an assumption that is heretofore unquestioned: redshift is a near-direct measure of velocity. Given that, then you have an 8-12 billion year estimate. If you add in inflationary theory, some cross-checking will get you 13.7 billion years as a best guess. More recent mainstream decelerate-accelerate theories vary the estimate somewhat.
However... what if it's not that simple?
Jesus, I just had a look at that thing. I've gone through the patent rigmarole a couple of times myself (still a couple pending), and must say that this out-fluffs our fluffiest patent by an order of magnitude.
Take away the standard boilerplate for 'can be run on any kind of terminal', and the preferred embodiment taken from a diagram in a database class tutorial workbook, and you're left with practically nothing. This isn't an invention, it's an idea.
As a software developer, someone can come up with the likes of this in their head during two minutes of idle chatter. Throw a tape recorder in any shoot-the-breeze session at an operations meeting every week, and you could churn out 50+ of these things a month. That's not where the real work is. It's not like describing a catalyst process that can shave your energy costs by 20%, or discovering a 5-step process to make finasteride. They've just thrown fancy words around a business requirement.
As a software developer, I worry that I tread on hundreds if not thousands of these things, just in the process of doing completely independent business. There are certain processes that have to be done to meet a business requirement that you don't need anyone else's patent to solve:
Many software patents contain no useful information. The recipes on the back on food cans convey more information, and can at least lead to a practical result. If you've got the time, just start flipping through a few on the USPTO site (start at anything 6,000,000 or past it). A great many of them can be conveyed in their entirety just by their title. Try handing these to one of your development team and say "make this". Next, try hiding the patents on day 2 and see if anyone notices. They won't, because there's nothing inside them worth referring to.
I'm bitter only in that it's only good manners that are keeping idea and obvious patents from being used against the rest of us in a giant legal Whack-a-Mole game, and for the risk of being put out of business by an unscrupulous patent holder, we get precious little value from other peoples' patents. We're not licensing inventions, we're buying indemnity insurance. I wouldn't be so all up-in-arms if licensing a software patent could actually gave us even a couple of weeks' head start in a project. You're not getting any source code. If you're lucky, there are screenshots of the "preferred embodiment". Apart from that, you get a few diagrams. How many millions is that worth?
On the plus side, if you have patents, you can sell your company for more :)
I know that biotech and engineering companies try to slide by some pretty dubious patents, but even they can't hold a candle to our industry.
I do hope the headlines over this sort of thing continue. It's far too easy to go back to being complacent if things calm down again.
-- A concerned developer
Still use it every day here as well. I've always found it the best compromise between speed of development, type safety, power, and ease of finding easy-to-grab components for everything from GIS to on-screen gauges to internet suites. Thumbing around Torry's or efg's Computer Lab provides a nifty, but very small, sampling of what's out there.
I'm actually pretty glad to see it's catching on again. We just attended the Delphi Diamondback/2005 roadshow, and I was impressed at the number of folks there compared to what I've seen in past years. Things are starting to pick up at the user group as well. I'll be demoing AQTime from Automated QA, a freakishly fantastic product for the price (from a corporate view, anyhow ;)
I've been actually not been terribly compelled to upgrade from Delphi 5 as a development platform. Not that later versions haven't been good, but the upgrades have been mostly in areas I'm not doing anything in, like the n-tier and web pieces.
We always upgrade one copy, though, and I attend conventions as I can. When Delphi for .NET came out, I was pretty seriously impressed. They put a lot of care and attention into making sure that ports from Win32 would be as painless as possible, but to let you go off and start off with native .NET and the FCL. Took less than a week to port my framework, and most of that was learning .NET idioms (like Finalize, strings being copy-on-modify, creating weak references).
You're often at the mercy of your component vendors, though, so if you were one of those that thought that the quality of the component code didn't matter as long as it worked... the pointer-trick and copy-and-paste coder segment will fall on tough times :)
Quite frankly, porting code, the trouble spots are basically:
Delphi 9, or Delphi 2005, as they're calling it, is the first compelling upgrade I've seen for folks like me, who spend a lot of time in the class interface design, source code and unit testing arena.
Delphi 2005 hosts three environments, Delphi/Win32, Delphi for .NET and C#. A lot of Delphi 8's language enhancements have made it into the Delphi/Win32 side, such as enumerator syntax (for MyString in MyStringList do...). The editor, at last, does a number of the refactorings that the JBuilder crew has had access to, such as Extract Method and a smart Declare Variable (e.g. X := MyControl.Parent will suggest TWinControl). The folding editor has a number of tricks up its sleeve, and a number of file backups are maintained which you can diff inside the environment, helpful if you run into troubles more granular than your version control system's checked-in versions. Nice to see some of the integrated tools and projects as well. New->Unit Test will give you DUnit (for Win32) or NUnit (for .NET) shells, and there are a ton more bits 'n' pieces I haven't had the opportunity to play with (the ASP.NET projects are pretty smooth).
Kylix was a bit before its time, really. Linux is such a freakishly fast-changing environment (as I sit here in my Fedora Core partition in utter awe of what yum says I must also update to update some of the major package around - gah!), and there isn't enough corporate-level interest in easy GUI programming for Linux to fund keeping up with it.
I got Kylix 2, and personally found it pretty good for porting, and a fairly decent environment (it used WINE, although apps made with it did not), although seamless it
"You CANNOT do unit testing. Think of the poor QA's who rely on our incompetence to feed their families.
*laugh* ...and our carelessness to feed them dessert :)
Unit testing is great to quash some of the "ghosts in the machine" before they happen, and to make maintenance more reliable - less guesswork about whether a refactoring or other maintenance change made something screw up.
Unit testing can cover off some things that QA just can't find because they never trip off a scenario QA comes up with. Saw a line to the effect of 'if (size<0) size=-size;' in someone's code the other day - who knows what the propagation of a negative size could do behind the scenes?
Where unit testing works less well-to-rather poorly is in the interface to 'real world' pieces, like talking to your LDAP server or communicating over modem. That's the realm of functional testing, and QA goes nicely with it. With a passel of tools (such as AutomatedQA's ones, or FIT for functional testing in some environments), QA can test out user entry scenarios, installs, stress-testing, running on different hardware and using different configuration files.
Most commercial developers I know like a relatively stable environment for developing in, and would be pretty averse to setting up and tearing down different versions of a database on their machine, or constantly booting to different OS versions to check things out.
No, what's more likely to make QA folks go hungry than anything else is corporate ignorance of how important they really are, especially when QA rightly gets in the way of releasing a buggy product :)
In all seriousness, I would STRONGLY suggest unit testing.
You bet! :) It can be a major conceptual hurdle to get over (my first thoughts were along the lines of 'why would I bother going "a.b = 1; check a.b == 1" - that's stupid!', but of course that's not what unit testing is about), but it's really, really worth it.
-- Ritchie
I've read many of the old (and new) 'push' gravity theories, the ones that theorize a particle carrier for gravity (I'll call them gravitons here). Where there are less gravitons, e.g. next to a body and more so between two bodies), you experience a lop-sided 'push' from areas of high graviton density.
With two bodies, you wouldn't be able to tell the difference - the absorption of gravitons would be measurable as though they were an appropriate pull.
Where you'd see a difference is in three bodies in a line, as the gravitons have to pass through two bodies on their way to the third, as the density (well, the flux) would already be minutely lower, hence a gravitational "shielding" effect (which would actually be more gravitational pushing from the other side).
These 'push' theories of gravity have waxed and waned in appeal over the past century or so (they're often called LeSagian theories, after Georges-Louis LeSage.) Part of the appeal is that they provide a mechanism for gravity, which GR does not truly provide (the theory of following geodesics in GR may explain paths objects take, but not why spacetime curves in that manner - what 'pulls down' on the 'fabric'?) There's a good collection of papers in Pushing Gravity which show some of the strengths and weaknesses of eight or so of the current push-gravity theories, and possible explanations of things like the anomalous in-track (and seemingly periodic) accelerations satellites can undergo.
Our theories may flip-flop a fair bit over time, but we do collect more data that needs explaining over time, and the anomalies do much more to further our understanding than the same ol'-same ol' ever did ;)
- Ritchie
It's bizarre. The universe could be teeming with life, or it could be utterly, completely barren save for us, and both alternatives would look pretty much the same to us.
Communication modes: Our communications are getting more focused, more noiselike (anyone remember what 300 bps sounded like compared to 56K compressed?), less tangible. Maybe the signal came 500 years ago. We couldn't have heard it. Couldn't have. At least the Professor on Gilligan's Island had a radio - coconuts wouldn't have worked. You can't hear radio without a radio (or finely-tuned braces). Who knows what the next physics breakthrough in modes of communication will be? Something quantum? Gravity-related? When it arrives, and if it's better, we'll switch over to it wholesale, and guaranteed we don't have receivers for it at present. Who knows what aliens would be sending their messages with?
Lucky in the life lottery: Perhaps it's easy for life to take hold on a planet, but maybe we're lucky to have had relatively complex creatures survive the multiple catastrophes. Folks sometimes theorize that Jupiter has protected us from some major calamities just by being big and in a further orbit, acting as dustbuster. Maybe life was seeded here from elsewhere. Wouldn't even have to be an organism - just a decayed crappy chunk of RNA-esque material would do for initial seeding purposes, and it would only have to happen once - one intact chunk out of millions of rocks. It took a heck of a long time to evolve multicellular organisms - the number just boggles the mind. Perhaps it's just that hard to evolve anything past single-cell organisms.
Planets: There seem to be a significant number of planets around. The program Celestia keeps a semi-current list of the detected planets and systems (so you can have fun visiting). Some of them, though, seem like there are gas giants way too big, or way too close to the sun, or are in a funny configuration. That's likely not conducive to life.
Age of the universe: I'm guessing, according to an increasing number of observations of late (mostly from the Hubble), that the universe is a lot older than we've been theorizing over the past few decades. The older it is, the more likely extraterrestrial life becomes.
The Ultimate Find: If we found someone, something out there, it would be the greatest discovery... well, practically ever. At least, "are we alone?" is something we've been asking for so long, and actually having a definitive answer would be amazing.
I think the voyages to Mars and (soon) Titan will inspire a new generation. Gads, if we can be that surprised in our own solitary back-yard...
I don't know if we'll find anything out there. I remain hopeful, but I certainly don't have "faith" in anything being out there.
-- Ritchie
I think simply !/$ is more appropriate.
But... you'd run into serious trouble if you got the book for free!
...**infinite bang**
-- RitchieThe best defense against a client-side blowup is to have as many layers as possible helping out, because they all have their various strengths and vulnerabilities.
In development:
QA:
Support and IT
Also, the ability to search inside files for phrases is horribly messed. It *never* finds phrases that I know are in the files I'm searching through.
Ran into that one fairly quickly trying to search through source code files - I'm a bit disappointed at their lack of search type 'fail-over', where if it doesn't recognize an extension, it seems to do nothing, but here's a KB article on the problem.
Humans don't come out as a tabula rasa with their behavior purely economically calculated. There are some mutations and bad family lines, to be sure, but humans have a code of conduct 'wired' into them by emotions... what makes them happy, guilty, angry, etc.
Putting Asimov-style Laws into robots is perhaps inadequate. The behavior that the Laws engender should make the robots happy - then it's not just a matter of a bad Law chip to let robots run rampant, they will have learned all their lives what makes them happy, not just be a big ball of at best neutrality seething to get out.
That's assuming a decent semblance of a neural network, though, which can work well through motivation and would lead to some consistency of behavior. If, instead, it's lots and lots of procedural code that can be updated through wireless connections via Outlook, the human race as we know it would be boned.
There's a pallid yellow line jumping up from Borland Pascal Object to Delphi, which you can just barely make out crossing the snake in the background.
The missing piece that gets me is Borland Pascal Object starting from scratch in 1989 from Pascal AFNOR.
That's news to me who was working at the time, and TP 5.5 with the new object extensions came out, giving me an Object-Oriented Programming manual to pore through. It was a relatively natural extension of TP 5.0 syntax, which was already miles away (especially with its strings and units) from old UCSD Pascal.
That line should extend back to 1983 for Turbo Pascal 1.0.
IMHO-tep :)
As to the installer, I feel your pain. I have a number of things written in old TP, and there seemed to be something different about the installer - as though it used the CRT code calculation, but wasn't written in TP.
It did seem to be a one-time check, though, in the installer as well as in TP programs. I don't know what other modern equivalents there are to Mo'Slo, but from what I remember trying to install it on a 333 Mhz PC (who knows if there are more issues now?), it just needs to be slowed down to old computer speeds right at the beginning of the install. Perhaps a high-priority greedy process might work in a pinch.
Do it once, put in the hacked crt.tpu files and the like, and back up the whole directory structure.
Klaus Hartnegg has an astonishing variety of fixes for the problem as well (including replacement units, ways to put the fix into CRT.ASM directly, and .exe-patching utilities), stored on his site to lessen any dead link troubles.
Man alive, all for want of an algorithm that was forward-looking enough to predict 200 Mhz machines :)
Is "somebody else patented that before you did" a valid argument in patent law?
Outside of the US, yes - it's based on first-to-file. In the US, however, it's based on a first-to-invent system. That makes it more 'fair' (you can't get completely locked out of something you invented first), but it makes for a lot more legal wrangling, and the burden of proof can be fairly hefty (just another reason to keep good R&D records).
As it stands now, your children don't end up like steadily more badly-mutated humans because there's a 'pre-culling' process that goes on. Sperm with bad mutations die or never make it very far. Eggs undergo a lesser culling process. Embryos that have problems are by and large let go naturally by the body - and mostly with good reason.
Those 'proving grounds' reset most genetic troubles from generation to generation, something that we cannot do quite as well for our own cells.
Michael West's The Immortal Cell is a pretty interesting account of one researcher who has been chasing the dream for a number of years. It's pretty fascinating reading, and those who haven't been watching the field will be amazed at what we have not only figured out, but what we have actually accomplished.
One option that comes up for the shorter term is tissue cloning. There are actually a number of things we know already (some from Michael West's book):
(It seems we can also 'reset' cellular programs by de-alkylating histones - those big 4-piece wintergreen mints that DNA is wrapped around. Histone alkyl 'tails' seem to have a lot to do with telling a cell what it actually does. Some of West's research indicates that you can get this to happen as part of the tissue cloning process)
So, instead of using hard-to-procure human eggs, you can perhaps use rabbit eggs (I'm sure the Australians wouldn't mind) and have what amounts to basically switching Duracell batteries for Energizer batteries. You can then pick out the healthy clonal cells for division into tissues.
With genomics, proteomics and experimentation, we can find the hormones or hormone chains to specialize the cells into skin, retinas, livers or even bone marrow.
Bone marrow gets my vote as a worthy cause. Being able to produce blood from the DNA of known-good donors would provide a decent backup if the ideal solution - cloning blood from the patient's own DNA - can't be done in time.
Sure beats any other 'stem cell source' we can get our hands on.
The next steps would be to try repairing aging cells in situ. The two biggies to fix which researchers have identified are the shortening telomeres (chromosome caps) and mitochondria (they are more susceptible to mutation, being more bacteria-like and exposed to by-products of burning food for energy).
Some good news at least in that it seems that we might not induce cancer in an attempt to lengthen telomeres - although further testing will be required.
It's pretty amazing how far we've come, but the things that are going to make the difference are going into the pipeline now - expect pretty fantastic things in 20 years, perhaps even 15.
*laugh* Gads, it's the Dark X of the Month Club :)
If I may be philosophical for a minute...
We have a lot of observations that are pretty close to indisputable: we have spectra from other stars, we have comets visit the inner solar system periodically, there are other planets relatively close nearby. Where a lot of the flux is, is where we attempt to explain how such things got to be, or guess at the meanings or causes of things that we can't directly observe or experiment with.
It's hard to remember sometimes that the assumptions that go into a set of theories could themselves be wrong, and that the theories can support one another without ever actually proving the assumption correct.
Some of the most powerful theories are ones that survive new levels of direct experimentation. Take evolution; regardless of the furor it causes in some circles, it has survived from a period of time where nobody knew what "stuff" caused parents and children to look similar, and successive closer looks all the way up to the various Genome Projects have given it actual mechanisms and even experimental techniques.
The old Greek theory of vision resulting from ray emanations from the eye certainly wouldn't survive the advent of experimental biology, yet in its own time, it was entirely self-consistent (and raytracers behave as though it really were the case :)
It wasn't all that long ago that some theories we take for granted were still being hammered out. Take solar planetary formation. According to Gamow's One, Two, Three... Infinity, one of the major fights was between collision theory and accretion theory. Accretion theory makes so much sense to us these days - so what was the problem?
Well, back at the time, folks doing calculations determined mathematically that a planetary disk would not coalesce, but instead remain like the rings of Saturn. One way around this problem had the gaseous elements being removed by infall into the sun, but this caused profound troubles in that the sun would gain way too much angular momentum.
As it stands, the collision theory (formation from collisions between stars) ended up having more problems, and we ended up with accretion theory, with the lighter elements being blown away by solar wind/radiation pressure. The "Zodiacal Light" is assumed to be the remains of those lighter gases, but of that, we certainly can't be sure.
We can't be 100% sure of accretion theory, regardless, because we can't take perfect pictures of planetary systems in formation over millions of years. It's a good working guess, though - and as a corollary, it implies that most star systems have planets, which we seem to be finding (collision theory required a very infrequent condition, which would make planets rare).
Who knows what else out there is ready to be overturned? Gravity? (current assumption: caused by geometry) Velocity of galaxies? (current assumptions: Doppler is the cause of redshift) The Oort cloud (current assumption: there's a near-perfect sphere of comet nuclei that can be disturbed by passing stars enough to send comets our way, but not enough to distort the sphere... amongst other things ;)
Some cherished scientific beliefs will be overturned in our lifetimes. (Fortunately, of course, this will not stop our electronics and entertainment from working). There's still a hell of a lot more to discover than the "we're nearing the point when we've discovered everything" crew would have us believe.
...and that should be an exciting, not a disillusioning, thought.
*laugh* The star name + letter combination will have to do for the meantime. The roman numeral convention assumes that we know all the planets in a star system, so Earth being Sol III and Mars being Sol IV is just grand for us.
For jolly gas giants around far stars, though, we don't know whether there are any other planets in orbit, or at the very least, we don't know how many other planets there are. Someone observing our system with the equivalent of our current technology wouldn't even be able to discern Jupiter or Saturn.
When we somehow (and I'd love to see how!) manage to figure out an entire remote planetary system, perhaps we'll switch back to roman numerals :)
Celestia keeps relatively up to date with discovered extrasolar planets, and it uses the star + letter convention. Obviously, though, the planet texture used when you go visit the planet is merely a guess :)
Um, they have everything to do with priority inversion. (http://www.us.design-reuse.com/articles/article24 2 5.html)
I would find it an odd design to schedule two threads of different priority on the same critical section, outside of perhaps device drivers and RTOS applications. Mutex protocols are an optional add-in to threading libraries (e.g. on AIX, here), for those instances where you would design such interaction - it's not going to happen by chance. Those interactions wouldn't be likely to happen in more than one or two "hot spots" in an application - and I would surmise those would be on the 'edges'.
Mind you, I don't know what kind of specialized software you write. It sounds like something that approaches needing realtime priority.
I have found NT to have horrible thread scheduling in a real multithreaded app.
For the priority inversion scenario, certainly. Here's an article on how NT deals with priority inversion. In practice, I've found that there's a subtle order-of-operation difference that can make a Linux/Unix-optimized approach go slower (relative to its theoretical performance) on NT, and vice versa. If I recall correctly from some of my porting efforts, NT tends to set up the new thread, continue running on the current thread, and lets the scheduler switch to the new thread later, and Linux tends to fork to the new thread immediately and lets the schedule switch to the old thread later. I was glad of the difference at one point; my thread pool suffered from a race condition I had overlooked - Linux's switching model ran into my bad assumption situation almost every time.
I guess I'm special, since I can count up to 1024 on my fingers! 1, 2, ..., 1024
*laugh* Ah, but can you count down to zero? :)
Right hand: thumb = 1, index = 2, middle = 4, ring = 8, pinky = 16
Left hand: pinky = 32, ring = 64, middle = 128, index = 256, thumb = 512
All fingers: 1+2+4+8+16+32+64+128+256+512=1,023 :)
No fingers: 0
Especially rude: 132 :)
How is windows dealing with priority inversion in just a few instructions?
Priority inversion? Critical sections don't have anything to do with priority inversion - the operating system is free to switch thread context at any time, including right in the middle of entering or exiting the critical section.
Are you thinking about the actual OS-internal constructs that prevent task switching or interrupts, or switch "rings"? Last time I dealt with those was the SEI and CLI instructions on the old 6510 processors. The only time those types of constructs should be touched is writing device drivers, and sparingly at that :)
Actually, to tell you the truth, when I first heard about critical sections, that's what I thought they were as well, and I steered completely clear of them, thinking that a single long critical section could grind the entire computer to a halt.
>Never, ever make a call to something you don't have complete control of, or that is even remotely large, inside a critical section<
Good luck on that one :-)
In practice, it's actually not that hard to avoid. Essentially, it means avoiding constructs like this:
MyPackets::ProcessPacketspacket_critical_section.enter
. packet = packets.dequeue
. process_packet(packet)
. destroy_packet(packet)
packet_critical_section.leave
But rather, use a construct like the following:
MyPackets::ProcessPacketspacket_critical_section.enter
. packet = packets.dequeue
packet_critical_section.leave
process_packet(packet)
packet_critical_section.enter
. destroy_packet(packet)
packet_critical_section.leave
The idea being that process_packet is potentially long and not under your control, so if someone was to add a packet (MyPackets::AddPacket) while process_packet was going on, that thread would be blocked, and it doesn't need to be (there's nothing inherent in adding a packet that's going to affect the processing of a previous packet).
destroy_packet can be assumed to be short and totally under your control (destroying objects shouldn't be a grand affair), and if the operation is simple enough, may not need to be in a critical section at all.
Does that shed some better light on what I was saying? :)
If you actually have many threads in your program critical sections can cause really bad performance and high unpredictable latency.
That doesn't actually have to be the case. The default case for a critical section is lightning fast. I've stepped through the assembly for NT's critical section, and the non-contention path is a mere handful of instructions long, including an LOCK INC instruction, which takes about 3x as long as an INC (which is not much).
The contention path, however, involves a WaitForSingleObject call, which, while not substantial, is certainly longer, and the performance hit mostly comes from the block, not the call per se.
The critical section itself is represented by a small, basically passive structure, representing the lock count and depth count, and not a whole lot else.
There are some simple rules that can make critical sections take the non-contention path 99.99 times out of 100, and profiling results bear it out:
I've seen violations of all of the above 'rules', and heck, yeah, performance suffers :)
Critical sections can badly impact performance, but I would guarantee that the problem is their use, not the construct itself!
Other mutexes on operating systems are typically equally fast unless they're being used for inter-process communication and must be accessed/looked up by name/atom.