To put it into context - must a parent always intervene in their child's life? Or must the parent allow the child to fail or get hurt at times so that they grow, mature, learn the most? It's the same with God, only he's the parent and we're all children.
So if your child was being tortured to death, you'd just stay out of it because it's a learning experience?
Me personally? No if I could help I would. But then think of the fall-out. If something happened to me as a result of my involvement would it not then have the same affect on my wife, children, parents, siblings?
But then you have to get back to the societal repercussions, of which we will always be far too small minded to comprehend. A change in one way (e.g. gun control) has adverse affects in another (e.g. self defense).
Where's the right balance? God knows; He even provided such a balance for us until we rejected it, deciding we knew better.
If a parent always intervened in every fight/etc on behalf of the child, how then would the child learn to defend themselves? How then would the child be able to defend their children?
If God always intervened, then would that not be agony in itself? If God had always intervened then Satan would not be able to exist, and everything would be determined - we would all be robots following out a fate predisposed before all. The fact that God does not always intervene leaves the possibility for free will - and all the potential horrors that come with it. Do you want choice or determinism where nothing that you do will ever make a difference?
To put it into context - must a parent always intervene in their child's life? Or must the parent allow the child to fail or get hurt at times so that they grow, mature, learn the most? It's the same with God, only he's the parent and we're all children.
per the summary: if you set it at $10 USD, then it sells for $7 USD - the 20% of the MSRP is $2 USD, but 70% of the retail sale price is $4.90 USD. So you'd get $4.90 USD instead of $2 USD. Good for you, good for Amazon. Now, if you try as others suggest and set the MSRP to $35 USD - 20% being $7 USD - but it conitues to sell for just $7 USD, then you'll get the $7 USD. If it sells for $6 USD, well, I would be very surprised if Amazon did not already cover that in the TOS; you'll likely only get $6 USD. Now those last two are, of course, assuming that the summary is correct; more likely than not, if the MSRP is a lot higher than the actual sale price - such that 20% MSRP is greater than or equal to the sale price - then Amazon will likely still only give you a percentage of the sale price as they do have costs too. My guess is that the summary writer did not fully read the TOS from Amazon, or it got mixed up in the PR publications they read.
Only if you're a developer. Apple charges the same fee, if I recall.
But don't let me get in the way of your anti-Microsoft ranting, informed or not.
And Google charges $25 for access to the Android Market Place. But you could also set up your own. Most Android phones can be configured to allow apps from outside the Android Market Place too.
A warning label on the box would have been warranted: "Note, your existing programs may not run in XP". Instead, they made every effort to make it look like all your programs would not only run, but run BETTER.
It has been very common for most of Microsoft's life that the majority of software would have major problems during a system upgrade. They've always gotten away with enough software being compatible enough to get the compatibility claim; but software - especially software that utilizes device drivers and hardware access - was always notorious for failing to work on newer software.
So while it could be expected the MS Excel 2.0 or AOL Instant Messenger would run and work; software like CD Burning software, or CD Ripping software, etc. has always had a high system upgrade failure rate.
Hell, half the software said "runs on Win 95 or later".
"Win95 or later" does NOT mean it will run on WinXP. It does mean that it is Win95 complaint and should also run on Win98, Win98SE, and WinME. But NOT WinNT4, Win2k, or WinXP.
It would be one thing if it also said "WinNT 4.0 and later" but that would have been very unlikely as most software targetted only Win9x, and not WinNT 4.x unless it needed the WinNT environment.
Most software houses did not start targetting WinNT until Win2k at the earliest. MS didn't force the issue until consolidating their OS'es with WinXP.
I wiped the drive before installing XP. Of course, I needed CD burning software, so I installed the software that came with the burner, AFTER installing XP. Had Windows not been written so shoddily, rather than letting me install it and then disabling it and my ability to uninstall it, it should have simply refused to install in the first place.
That's not MS's problem - but the software manufacturers. MS has no way of knowing by the installer whether or not it runs on only Win9x or WinNT. Granted, the mechanisms MS provides to different are extremely poor, but again - that's the software manufacturer's issue.
Of course, you probably should have looked for an updated version of the software too _before_ installing it.
Get real, Microsoft's software is WAY overpriced. ALL of it is way overpriced; at least, for an average Joe buying the software outright at a computer store.
While I agree here...
I paid over a hundred bucks for XP, upgrading from 98. I really felt ripped off. Not only did a lot of my old software no longer run,
Well, that's to be expected - especially in the 9x/Me->XP upgrade where the OS dramatically changed from the informal, DOS-based system that was 9x to the NT-based system that is XP and later. And early versions of XP were not the best at compatibility with 9x/ME software either.
Microsoft "disabled" the app that came with my CD burner, saying it was "unstable". I'd had no stability problems with 98.
Again - 98 (9x) was dramatically different from XP (NT) - the driver models, device access, etc. were completely different. It would have been quite remarkable if the CD burning software continued to work at all given that (i) such software on 9x had direct read/write access to the CD device and (ii) under NT such software has to go through specialized device interfaces to do the same thing, interfaces that were guaranteed to be different between 9x and NT. "unstable" was probably just a misnomer for "broken under NT".
What was worse, every morning when it booted it informed me that it had disabled this software, which it wouldn't let me uninstall.
Well, the 9x->XP upgrade process was not a very nice one given the dramatic differences in the registry and other system level changes. Yes, XP had a way to import parts of the 9x registry; but it wasn't very good at doing so.
I had to reinstall XP to get rid of the app it had disabled! Shoddy, shoddy software. Consumer protecteion laws ARE warranted in my view.
When upgrading any version of Windows (even 95->98->ME) a clean install is really the only way to go.
Face it - you took the wrong installation/upgrade path. Perhaps you learned for the XP->Vista->W7 upgrade too.
And seriously - there's a reason why most people just buy a new PC to upgrade Windows - it's easier.
But it'll be hard to beat Qt's threading interface.
I don't know much about Qt's threading, but does it offer anything dramatically different than locks and mutexes?
I'll take a look into Erlang...
Qt does have support for locks and mutexes, and you could certainly use them in the traditional manner. However, it is very easy to write full programs with multiple threads without using a single lock or mutex in Qt and be perfectly safe in doing so if you use an QThread with Qt's Event Loop and Signal/Slot architecture. The whole program becomes very asynchronous as a result, but you never need a lock yourself - Qt's underlying functionality provides all the thread protections you need.
Now some of that is dependent on how you want to use the objects, and requires a big mental shift in programming methodologies. But I'd guess it's probably the same effect that Erlang has - at least from what I can tell from the documentation.
Hey now... I was in high school in the late 90s and our computer science class was centred around Turbo Pascal. I learned a lot writing Pascal programs, and for my final project my lab partner and I wrote a graphical RPG including an on-screen scrolling-text display we wrote from scratch. The year after I left, they switched to C++.
I know Javascript, BASIC, Pascal, a bit of Perl, but not any C. And while I feel that every CS student should come away knowing it, I'm also thankful to these other languages for teaching me the fundamentals of program logic.
Agreed. We had Pascal, C++, and QBasic (later Visual Basic). I had C++ before Pascal, and then ported a number of C++ classes to Pascal - including a C++ mouse driver that used inline assembly. Pascal is quite a nice language and has its strengths. It's just not as flexible or useful as C++ any more.
Java has its advantages as a slightly better C++ with a lot of enterprise infrastructure around it. But so much stuff is just painfully almost right with it (the generics as you mentioned, the separation of primitive types and objects, the handling of null, the way it still doesn't have closures...), I find myself hoping C# pushes it aside soon.
C# will never push Java aside. C++ with Qt, or C++ with BOOST may; but never C#.
I don't see multiple inheritance as a vital feature. As you've stated, it is possible to work around it without much hassle. So, it may be very useful and convenient but it is not a vital feature.
That being said, the reason I made a point of mentioning multiple inheritance was to point out how absurd LizardKing's comment was. You simply cannot claim that a particular implementation is "so much better" than another when the allegedly better implementation at best implements some fundamental features in a half-assed way and at worse simply fails to implement them. As this is a (somewhat) technical forum, people must limit themselves to the facts regarding the technology and avoid unleashing the fanboy in them to boast about their pet tech through absurd and patently false statements such as the ones which I've pointed out. It diminishes the technology and it denigrates the people who are seriously invested in it.
Suppose you have an API, example Qt, where Templates (e.g. generics) are not allowed. Now suppose you need to implement a feature using Template (e.g. generic), but you need it in an object native to that API. Well, you can do it in one of two ways:
Define a template class to do what you need; then define a new class that derives a specific instance of the template and is a native object of the API using MI to get both. Said class can simply be a type definition of the class.
Define a template class to do what you need. Then define a new class in the native API that contains an instance of the template class as a protected member with accessors (get/set/etc) for each property and method of the template class.
Which is easier? In case #2 you only have single inheritance but now you have to maintain the whole of new class object. In case #1, you can simply have a class that derives from both; so changes to the template class automatically happen in the new class, and vice versa - the only thing you may have to maintain is the constructor/destructor, but even Stroustrop suggests to not even write those if you can - so you could get away with a simple "class newClass: public apiObject, templateObject {};" for the definition.
Now, why might you need to use a template to do something that way? Certain kinds of solutions - e.g. ring buffers, service applications - are better defined as templates especially when dealing with a multi-platform scenario. However, some APIs - e.g. Qt - don't allow some functionality of languages like C++ due to the inherent complexity. (E.g. Qt's MOC tool would need to be able to fully understand and interoperate with C++ templates; not an easy thing to do.)
Java multithreading is barely better than C++. It's analogous to GOTO. If you want something more structured, try Erlang.
Java multithreading is no where near as good as C++ combined with Qt, and there is no need for GOTO in there either.
C++ combined with POSIX threads, or MFC Threading, is a bit terrible yes. It's not hard to write a better threading interface. But it'll be hard to beat Qt's threading interface.
I don't like Java much myself, but I don't see it going anywhere. A staggering amount of java based (Android?) devices are shipped daily. Once the iPad version is released you may even see some folks switching (back) to it.
Android does not support Java. Android Apps are not Java programs.
Yes, you can develop Android apps in a Java Environment, but they are actually non-Java. To be Java, they would have to run on the Android device in a JavaVM. The Android SDK is simply Java-compatible for ease of us - much like C++ and ObjectiveC are both C compatible.
I'm wondering what Oracle's angle is on this. They haven't been particularly concerned with developers walking out in a mass exodus. Or is it just a matter of it looking really bad for them to lose that support?
They probably see ASF as a big community player and want them on board; but unless ASF can put Harmony through and gain 100% acceptance as a Java implementer without the conditions that Sun/Oracle have imposed then there is no reason for them to stay in the JCP.
If they really want to bring ASF back, they'll let Harmony use the test kit as ASF desires without limitation. That's probably all it would take.
Actually, the predicted speeds for racetrack memory are rather close to RAM speeds. It could be possible to operate it as primary storage - it would be a bit sluggish for calculations, but it would eliminate the need to read in chunks of files to be operated on. Given the increasing size of L3 cache, it could be possible for racetrack memory to replace SSDs and RAM while pushing hard drives into the "long-term storage" role, and have the L3 cache take the role of RAM.
This isn't a firm prediction - I'm not even sure racetrack memory will come to anything, but if it does, "the death of RAM" is entirely possible.
I'll agree the death of RAM is certainly possible if its fast enough. However, it will likely have a lot better life with less moving parts than a traditional hard drive. So I would see traditional hard drives definitely going away - SSDs will do that by themselves once they get cheap enough even without Racetrack memory taking on hard drives and SSDs. So I could see the long-term storage going to SSDs or Racetrack memory-based hard drives; but traditional hard drives will certainly die at some point. It's just a matter of the cost coming down enough to make it worth it on the other forms first.
Linux has pretty much won over closed source. Appliances run Linux, supercomputers run Linux, servers run Linux. About the only place Linux as an OS doesn't dominate is on the desktop.
Now, with Android, Linux is dominating in phones.
And Microsoft is scared of it too...so it's probably just a matter of time for the Desktop - but that will probably degenerate into a two (Linux+Mac) or three (Linux+Mac+Windows) way split, with Linux at least slightly leading over the other players.
Not really. PC's use blacklists. iPhones use whitelists, but poorly vetted ones. What is proposed is well vetted greylists that harness competition to make them well vetted. Say you write malware. Great. Now you still have to submit it to the store which means the store operator vets it and all other security lists are notified that it exists. On top of that, since it had to declare an ACL to get into the list, a cursory inspection is all that is needed to determine if the ACL matches up with the app's feature-set in most cases.
That might be ok for malware writers like comScore, but the normal malware writer is aiming to take advantage of flaws in software - not go through a appstore kind of place.
Yes, SELinux and similar things have great tracking and abilities to prevent things from happening that shouldn't - but you can still take advantage of a flaw in the system, albeit it'll be a lot harder to do.
So again, you're imposing restrictions on what people want to legitimately do while not increasing the difficulty for the true problems by any order of magnitude.
And while you're "vetted greylists" idea sounds interesting, I doubt competition would bring about what you describe - it hasn't already for what exists.
Slashdot Mirror
But being all-powerful and all-knowing does not necessarily mean always interfering. Sometimes there are bigger things at play - things we cannot see.
I never said God is afraid of getting hurt - otherwise he wouldn't have let himself get hurt.
To put it into context - must a parent always intervene in their child's life? Or must the parent allow the child to fail or get hurt at times so that they grow, mature, learn the most? It's the same with God, only he's the parent and we're all children.
So if your child was being tortured to death, you'd just stay out of it because it's a learning experience?
Me personally? No if I could help I would. But then think of the fall-out. If something happened to me as a result of my involvement would it not then have the same affect on my wife, children, parents, siblings?
But then you have to get back to the societal repercussions, of which we will always be far too small minded to comprehend. A change in one way (e.g. gun control) has adverse affects in another (e.g. self defense).
Where's the right balance? God knows; He even provided such a balance for us until we rejected it, deciding we knew better.
If a parent always intervened in every fight/etc on behalf of the child, how then would the child learn to defend themselves? How then would the child be able to defend their children?
If God always intervened, then would that not be agony in itself? If God had always intervened then Satan would not be able to exist, and everything would be determined - we would all be robots following out a fate predisposed before all. The fact that God does not always intervene leaves the possibility for free will - and all the potential horrors that come with it. Do you want choice or determinism where nothing that you do will ever make a difference?
Sometimes the greatest strength is to not get involved.
To put it into context - must a parent always intervene in their child's life? Or must the parent allow the child to fail or get hurt at times so that they grow, mature, learn the most? It's the same with God, only he's the parent and we're all children.
per the summary: if you set it at $10 USD, then it sells for $7 USD - the 20% of the MSRP is $2 USD, but 70% of the retail sale price is $4.90 USD. So you'd get $4.90 USD instead of $2 USD. Good for you, good for Amazon. Now, if you try as others suggest and set the MSRP to $35 USD - 20% being $7 USD - but it conitues to sell for just $7 USD, then you'll get the $7 USD. If it sells for $6 USD, well, I would be very surprised if Amazon did not already cover that in the TOS; you'll likely only get $6 USD. Now those last two are, of course, assuming that the summary is correct; more likely than not, if the MSRP is a lot higher than the actual sale price - such that 20% MSRP is greater than or equal to the sale price - then Amazon will likely still only give you a percentage of the sale price as they do have costs too. My guess is that the summary writer did not fully read the TOS from Amazon, or it got mixed up in the PR publications they read.
Only if you're a developer. Apple charges the same fee, if I recall. But don't let me get in the way of your anti-Microsoft ranting, informed or not.
And Google charges $25 for access to the Android Market Place. But you could also set up your own. Most Android phones can be configured to allow apps from outside the Android Market Place too.
It has been very common for most of Microsoft's life that the majority of software would have major problems during a system upgrade. They've always gotten away with enough software being compatible enough to get the compatibility claim; but software - especially software that utilizes device drivers and hardware access - was always notorious for failing to work on newer software.
So while it could be expected the MS Excel 2.0 or AOL Instant Messenger would run and work; software like CD Burning software, or CD Ripping software, etc. has always had a high system upgrade failure rate.
"Win95 or later" does NOT mean it will run on WinXP. It does mean that it is Win95 complaint and should also run on Win98, Win98SE, and WinME. But NOT WinNT4, Win2k, or WinXP.
It would be one thing if it also said "WinNT 4.0 and later" but that would have been very unlikely as most software targetted only Win9x, and not WinNT 4.x unless it needed the WinNT environment.
Most software houses did not start targetting WinNT until Win2k at the earliest. MS didn't force the issue until consolidating their OS'es with WinXP.
That's not MS's problem - but the software manufacturers. MS has no way of knowing by the installer whether or not it runs on only Win9x or WinNT. Granted, the mechanisms MS provides to different are extremely poor, but again - that's the software manufacturer's issue.
Of course, you probably should have looked for an updated version of the software too _before_ installing it.
While I agree here...
Well, that's to be expected - especially in the 9x/Me->XP upgrade where the OS dramatically changed from the informal, DOS-based system that was 9x to the NT-based system that is XP and later. And early versions of XP were not the best at compatibility with 9x/ME software either.
Again - 98 (9x) was dramatically different from XP (NT) - the driver models, device access, etc. were completely different. It would have been quite remarkable if the CD burning software continued to work at all given that (i) such software on 9x had direct read/write access to the CD device and (ii) under NT such software has to go through specialized device interfaces to do the same thing, interfaces that were guaranteed to be different between 9x and NT. "unstable" was probably just a misnomer for "broken under NT".
Well, the 9x->XP upgrade process was not a very nice one given the dramatic differences in the registry and other system level changes. Yes, XP had a way to import parts of the 9x registry; but it wasn't very good at doing so.
When upgrading any version of Windows (even 95->98->ME) a clean install is really the only way to go.
Face it - you took the wrong installation/upgrade path. Perhaps you learned for the XP->Vista->W7 upgrade too.
And seriously - there's a reason why most people just buy a new PC to upgrade Windows - it's easier.
I'll take a look into Erlang...
Qt does have support for locks and mutexes, and you could certainly use them in the traditional manner. However, it is very easy to write full programs with multiple threads without using a single lock or mutex in Qt and be perfectly safe in doing so if you use an QThread with Qt's Event Loop and Signal/Slot architecture. The whole program becomes very asynchronous as a result, but you never need a lock yourself - Qt's underlying functionality provides all the thread protections you need.
Now some of that is dependent on how you want to use the objects, and requires a big mental shift in programming methodologies. But I'd guess it's probably the same effect that Erlang has - at least from what I can tell from the documentation.
Hey now... I was in high school in the late 90s and our computer science class was centred around Turbo Pascal. I learned a lot writing Pascal programs, and for my final project my lab partner and I wrote a graphical RPG including an on-screen scrolling-text display we wrote from scratch. The year after I left, they switched to C++.
I know Javascript, BASIC, Pascal, a bit of Perl, but not any C. And while I feel that every CS student should come away knowing it, I'm also thankful to these other languages for teaching me the fundamentals of program logic.
Agreed. We had Pascal, C++, and QBasic (later Visual Basic). I had C++ before Pascal, and then ported a number of C++ classes to Pascal - including a C++ mouse driver that used inline assembly. Pascal is quite a nice language and has its strengths. It's just not as flexible or useful as C++ any more.
Java has its advantages as a slightly better C++ with a lot of enterprise infrastructure around it. But so much stuff is just painfully almost right with it (the generics as you mentioned, the separation of primitive types and objects, the handling of null, the way it still doesn't have closures...), I find myself hoping C# pushes it aside soon.
C# will never push Java aside. C++ with Qt, or C++ with BOOST may; but never C#.
I don't see multiple inheritance as a vital feature. As you've stated, it is possible to work around it without much hassle. So, it may be very useful and convenient but it is not a vital feature.
That being said, the reason I made a point of mentioning multiple inheritance was to point out how absurd LizardKing's comment was. You simply cannot claim that a particular implementation is "so much better" than another when the allegedly better implementation at best implements some fundamental features in a half-assed way and at worse simply fails to implement them. As this is a (somewhat) technical forum, people must limit themselves to the facts regarding the technology and avoid unleashing the fanboy in them to boast about their pet tech through absurd and patently false statements such as the ones which I've pointed out. It diminishes the technology and it denigrates the people who are seriously invested in it.
Suppose you have an API, example Qt, where Templates (e.g. generics) are not allowed. Now suppose you need to implement a feature using Template (e.g. generic), but you need it in an object native to that API. Well, you can do it in one of two ways:
Which is easier? In case #2 you only have single inheritance but now you have to maintain the whole of new class object. In case #1, you can simply have a class that derives from both; so changes to the template class automatically happen in the new class, and vice versa - the only thing you may have to maintain is the constructor/destructor, but even Stroustrop suggests to not even write those if you can - so you could get away with a simple "class newClass: public apiObject, templateObject {};" for the definition.
Now, why might you need to use a template to do something that way? Certain kinds of solutions - e.g. ring buffers, service applications - are better defined as templates especially when dealing with a multi-platform scenario. However, some APIs - e.g. Qt - don't allow some functionality of languages like C++ due to the inherent complexity. (E.g. Qt's MOC tool would need to be able to fully understand and interoperate with C++ templates; not an easy thing to do.)
Java multithreading is barely better than C++. It's analogous to GOTO. If you want something more structured, try Erlang.
Java multithreading is no where near as good as C++ combined with Qt, and there is no need for GOTO in there either. C++ combined with POSIX threads, or MFC Threading, is a bit terrible yes. It's not hard to write a better threading interface. But it'll be hard to beat Qt's threading interface.
I don't like Java much myself, but I don't see it going anywhere. A staggering amount of java based (Android?) devices are shipped daily. Once the iPad version is released you may even see some folks switching (back) to it.
Android does not support Java. Android Apps are not Java programs.
Yes, you can develop Android apps in a Java Environment, but they are actually non-Java. To be Java, they would have to run on the Android device in a JavaVM. The Android SDK is simply Java-compatible for ease of us - much like C++ and ObjectiveC are both C compatible.
The Dalvik VM is NOT a JavaVM.
I'm wondering what Oracle's angle is on this. They haven't been particularly concerned with developers walking out in a mass exodus. Or is it just a matter of it looking really bad for them to lose that support?
They probably see ASF as a big community player and want them on board; but unless ASF can put Harmony through and gain 100% acceptance as a Java implementer without the conditions that Sun/Oracle have imposed then there is no reason for them to stay in the JCP.
If they really want to bring ASF back, they'll let Harmony use the test kit as ASF desires without limitation. That's probably all it would take.
Actually, the predicted speeds for racetrack memory are rather close to RAM speeds. It could be possible to operate it as primary storage - it would be a bit sluggish for calculations, but it would eliminate the need to read in chunks of files to be operated on. Given the increasing size of L3 cache, it could be possible for racetrack memory to replace SSDs and RAM while pushing hard drives into the "long-term storage" role, and have the L3 cache take the role of RAM. This isn't a firm prediction - I'm not even sure racetrack memory will come to anything, but if it does, "the death of RAM" is entirely possible.
I'll agree the death of RAM is certainly possible if its fast enough. However, it will likely have a lot better life with less moving parts than a traditional hard drive. So I would see traditional hard drives definitely going away - SSDs will do that by themselves once they get cheap enough even without Racetrack memory taking on hard drives and SSDs. So I could see the long-term storage going to SSDs or Racetrack memory-based hard drives; but traditional hard drives will certainly die at some point. It's just a matter of the cost coming down enough to make it worth it on the other forms first.
So you string together some quantum-nanobits and call it a day.
I'd prefer the Who, What, and Where. It'd be a "Who's True" comedic relief.
Microsoft: all about being eX-Professionals.
Research SHOULD fail regularly ("fail" in this sense being "did not lead to areas to develop.").
Sometimes, somewhere along that chain, Research SHOULD have failed but somehow hiccuped and still went into development.
And then we got Windows Millenium Edition.
No, that's how we got Windows - all of 'em.
There have already been exploits to break out of Virtual Machines (e.g. VMWare) and various sandboxing techniques.
Linux has pretty much won over closed source. Appliances run Linux, supercomputers run Linux, servers run Linux. About the only place Linux as an OS doesn't dominate is on the desktop.
Now, with Android, Linux is dominating in phones.
And Microsoft is scared of it too...so it's probably just a matter of time for the Desktop - but that will probably degenerate into a two (Linux+Mac) or three (Linux+Mac+Windows) way split, with Linux at least slightly leading over the other players.
That might be ok for malware writers like comScore, but the normal malware writer is aiming to take advantage of flaws in software - not go through a appstore kind of place.
Yes, SELinux and similar things have great tracking and abilities to prevent things from happening that shouldn't - but you can still take advantage of a flaw in the system, albeit it'll be a lot harder to do.
So again, you're imposing restrictions on what people want to legitimately do while not increasing the difficulty for the true problems by any order of magnitude.
And while you're "vetted greylists" idea sounds interesting, I doubt competition would bring about what you describe - it hasn't already for what exists.