It's possible they could counter sue. Other than that, there are court costs. You should always consult a lawyer, so unless you have a lawyer friend or no real assets that they could claim, then it's probably not realistic. I wasn't really serious.:)
If you really want to take them to court, you can sue them for damages as well as legal costs. It would require some time and money... The likes of which you probably don't want to invest.
If you want to DoS SCO to shut them up... DoS their lawyers. Go to your local courthouse and file a civil suit against them complaining that they are harming your Linux business with their libelous claims. That'll drain their funds quicker than a DoSing virus, even if you loose.
For one, the TLB has to be bigger for 64bit addresses.
Secondly, even RAM running at 333MHz can only switch pages at about 111MHz optimally. Everytime you leave a 4K barrier, you might as well put 20 NOP's in your code.
You're going to have some cache misses... It's best if you try to make them only have to do a row select on RAM. If you have huge data structures that warrent 64bit addressing, you aren't going to have as much cache to help prevent this. In fact, you should be flipping pages almost all the time.
When allocating memory for objects, you should allocate it all together, and you need to set a maximum size for your object, then use relative addressing.
The neat thing about VMs is that they will do this for you. Some defragment your memory periodically. They manage all your pointers, so they know what size they should be. VMs generally allocate contiguous heaps of memory to avoid paging when possible too. There are a lot of advantages to VM software, that until recently haven't been leveraged enough to make it show on benchmarks.
You can claim it is a compromise, if you want, but it is not both an advantage and a disadvantage. Parts of it are to your advantage, others may be to your disadvantage, but on a whole it can be one, the other, or neither. That's like saying that a=1+2i and b=2+1i then claiming that ab because different parts are greater. On a whole they are equal in magnatude, abs(a)=abs(b). They just go in different directions.
I hate it when slashdot tries to parse as html in "plain old text" mode.
I absolutely hate when the techies requesting the job have a typo in an acronym, and you get a phone interview. "I didn't see on your resume if you had an EBJ experience." They don't understand that EJB was what was meant, and that discredits your experience. Someone will eventually say, "Yes, I have 2 years of EBJ experience" and when they get through HR, they'll get the job because they just made you look like an ass that didn't know what "EBJ" was.
Another problem I have is requiring more than a year of experience in anything. If you can't learn it by using it for a full year, you would have been fired about two months into the last job.
I really enjoy working with technical recruiters more because they actually know what the hell they are talking about most of the time, and they work through HR, so there really aren't any problems like that.
That said, I've had probably 20 phone interviews, a good percentage saying they were going to try to set up an interview with tech staff. So far, only one of them has come through, and they are a recruiter. I really just think there is a shortage of actual jobs. I've customized my resume for positions before and received no response at all. Needless to say, I don't bother with that company any more considering I put forth hours of effort, and they didn't have 30 seconds to say "No, we're sorry, we can't use you. If something comes up, we'll give you a call." then ignore me. I figured they have an email template for that kind of thing. An auto-responder would show more respect. Bad peer reviews of companies go a long way too. I have neglected to apply to a few companies because I've been told of their practices. You would think that the HR department's existence is to prevent this situation.
No, they'll just remove whatever has been shown to be offending code, replace it, and move on like SCO never existed.
BSD doesn't even have a GPL license, which will offend some people. BSD is Darl's next target.
I wished it meant switching kernels, because then it would be everyone working on the HURD, which is a designed system, not an ad-hoc bundle of code migrating to a design. Unfortunately, designed systems take longer to make, and thus are abandoned as being inferior because of limited insight of the general population. Most people just want something that works, some of us want something that works, is easily extendable, has a consistent API, and is scalable.
Before anyone replies with some nonsense about HURD/Microkernels not being scalabale because of context switches, please do shoot yourself in the head for confusing speed and scalability. As for those going to reply about Mosix extensions to Linux, please slap yourself for not reading what I said about Linux evolving toward design. With the proper support, the HURD would probably have had better functionality than Mosix about a decade ago.
I gaurantee you that you'll have more data in the class than the pointer to it always... or else you're just being really stupid. I'm also assuming that most people are going to have long addresses and many phone numbers. If you add in the other fields to those objects, I think you're looking at your data being anywhere from 10-30% pointers even in a 64bit world.
Most pointers are code relative jumps IE function addresses. Most people should probably look more for data segmentation than absolute addresses anyhow, especially on embedded devices where memory tends to be much slower. Switch pages only when you need to. Most 64bit addresses are only going to need maybe 4-8 bits above the 32bit mark... even for VM. It would probably be better to store 8bit pointers then combine them with a 32bit offset to generate the 64bit absolute address. I can't think of many application that would benefit from the terabyte of address space this would give though. You're application will likely not need that for memory addressing.
Like I said in a previous post, there are ways to work around it for huge databases too. 4K disk blocks * 2^32 = 16TB database. I don't know of any database that has crossed the terabyte threshold yet, but it's very likely there are some... On the kinds of machines that you would use databases that large, it's still going to be better to increase the disk block size than the 32bit pointers. It's not uncommon to have 64K clusters on desktop machines these days... Thats 256TB.
Most 64/32bit hybrid machines probably just split the arithmatic/logic units in half (just takes a single wire to connect them anyhow). Having an extra ALU around will surely push more 32bit numbers through the pipe. It's not going be as fast as a 64bit optimized application would gain from having the combined operations should it need them though.
I'm beginning to wonder these days how much CPU speed even matters though. We have larger applications that can't fit in cache, page switching from RAM that isn't anywhere near the speeds of the CPU, and hard drives that are only 40MB/s on a good day/sector, with latency averaging around 5-6ms. CPU is the least of my worries. As long as the hard disk is being utilized properly, you'll probably not see significant differences between processor speeds. I'm a firm believer that people think that 500MHz is slow because the hard drive in the machine was too slow. Unless you are running photoshop, SETI, Raytracing, etc., you probably wouldn't notice if I replaced your 3GHz processor with a 1GHz.
I think the cache arguement is complete BS. It appears it would be true, but not really. Most pointers are created and controlled by the compiler, and they are going to be relative 90% of the time. That's why relative addressing was invented. So, you get an extra 4 bytes stuffed into your cache on the relatively rare occurance that one of your 8 byte pointers are being used. In this 8 byte pointer, I'm just going to assume that you aren't idiot enough to be accessing memory in the same page most of the time. I really think that the page switching of the RAM to access the data at the other end of the pointer is going to be the greatest overhead. Normal cache misses in a 64bit addressing scheme should be exponentially more than a 32bit, if you really needed the 64bit.
So while you may have a caching problem, I think it's going to be because of accessing more data rather than the 4 bytes extra on some pointers.
Now if you're using disk based data structures, you better be using 64bit. I could make an exception if you used a 32bit number to address the cluster, then a 16bit number to access the actual data in the cluster, if required. A good DB server would do well to use 32bit cluster numbers to save index size, then scan the loaded cluster for the record. AFAIK, no one has been clever enough to do this, but I'm not privy to the internal structures of a lot of DBMSs. And this would matter a lot, because you could fit much more of the index into memory, and have much less data to read on the drive. Throwing away CPU cycles and memory for more compact disk data is a common practice.
Then from the obvious observation that you can tell a sine and a triangle wave apart, you should come to the obvious conclusion that in your model a human can detect signals up to about 100KHz. I prefer to think of it more as:
There are two theories for you:
1) Recording devices don't clamp signals exactly at the desired frequency, so signals >22Khz that obviously do exist are interfering with the 22KHz signals in a way that distorts the wave when you try reconstruct it.
This theory doesn't hold because experiments involving humans and the higher frequencies showed that even with analog equipment, humans can detect the difference. This theory does show that Nyquist theory doesn't apply, because the Nyquist theory states that there must not exist any frequency signal above the one you are trying to capture.
2) Fourier theorem doesn't apply to human hearing because human's don't hear frequencies at different levels, they hear the shape (for lack of a better word) of the wave as well, so they can detect the frequencies up to 100KHz, but not hear them.
This is the place where you were supposed to introject a counter theory, not attack my knowledge of Nyquist and Fourier theories. They are both mathematical models. Recording devices sampling back at the same rate are not going to tell a difference because they rely on those same theories. Human's aren't going to like it any more than sticking the wire from the DAC on their tounge because the principals, as of yet, have not involved human perception. At least my monitor's mathematical model took into account the frequency response of my eye. I grow very tired of people testing the principals of their design with systems that assume the principals of their design.
Nyquist and Fourier theories are all nice and good when they are applied to the field they were intended, neither of which are human perception of audio. Nyquist theory applies very well to networks, and fourier works great at seperating and recombining waves. I doubt very much that you could apply fourier transforms in a way that you would understand speech, because that's not the way humans hear.
As you'll read, there has been research done, and it is noticable to chop off frequencies above 22KHz. Granted a single wave is not going to show the difference, but we more than likely detect that waves effects on other waves.
That's great! It's pretty much perfect. I hadn't looked at the new Creative cards. I've been using Live! for about 5 or more years now, and while I'm happy with it, analog has still been my friend.
I'll have to look at it's recording capabilities. They usually have a lot of options for that kind of thing.
You can not distinguish between sine and triangle waves with only 2 points per wave. You pick two points equidistant, and I'll draw a phase shifted sign wave through them. That is BAD! There is not enough information to properly construct a wave with only two points. There is only enough information to construct a sine wave if you already know the wave is a sine wave. I'm not disputing that if you can accurately represent 20KHz that you would have a problem representing 19KHz overlayed on it.
I gaurantee I know more about DSP than either of you know about music and audio equipment. I once was under the delusion that with enough DSP I could recreate an exact sounding digital implementation of a tube using transistors. I was doing this to digitally record my guitar. The reality of the situation set in while researching ADC (It's very expensive to even get a logarithmic comparitive ADC that can follow 192KHz at 16 bit accuracy (18bit internal)). And transistor charicteristics are more skewed than tubes, so it would take a greatter than 16bit accurate sample in order to map to the appropriate position without making generalizations about the shape of waves. I've seen several waves under O-Scope, and know quite well that they are not sine waves. I wrote some wave files with different wave forms and piped them through audio out, and it's more than noticable at any frequency, just like clipping a wave.
Even after you consider all this, you also have to compensate for speaker response, and microphone/pickup recording characteristics. Pickups on a guitar don't match so great with most audio systems, and you need to work on impedance mismatches.
To actually make a good digital guitar, I was looking at pretty much a PhD level project. In fact, I'm saving the project for just that. It combines extensive Math, CS, Art, EE, and a bit of physics. I very much plan on running both through an analog comparator where the speaker should be (with some phase and volume tuning of course) just to see how close it is. If I get 90% accuracy I'll consider the project a success.
I don't know where your assumption that at highest frequency response of a human ear, you can't tell the difference in waveform comes from, but I assume it comes from you piping sound back into a recording device that has a sampling rate. Yeah, you can reconstruct it so that a sampling device can't tell a difference, but we humans don't sample. Our hearing is a very much more complicated than that. Most people don't know that we use the delay of sound from one ear to another to determine the position of a sound's source. We can distinguish a wave from front or behind, with only two ears in a lot of cases. Feeling is also incorperated into our hearing as much as smell is to tasting.
If you stop making assumptions about human hearing from a DSP perspective, maybe you'll start to see yourself.
I learned Python and Zope both in two weeks, and I was quite able to make a database driven web-site in those two weeks while learning, that took me a month to make in PHP, and I had used PHP quite a bit in the past.
Comparing Zope to PHP, I think most people will come to the conclusion that not only is Zope easier to develop for, but also it's easier to maintain since it gently encourages you to move your data-access/queries into a seperate space.
I've had a Zope server running without a single hickup for about 2 months now. I'm also a J2EE guy, and since then, I've had JBoss bail out at least twice on some servers. It's very stable.
If you don't like zope, it'll be because the documentation is skimpy, or you'll be writting dynamic web sites in ASM just to get the last bit of performance out of it even though the data pipe is already satuerated:) Remember, the limiting factor for dynamic web sites is bandwidth. The second limiting factor is your DB/hard disk.
You're the highest ranking responder, so you get picked on:)
Just to answer other people in the thread about why you want the full audible range, there are harmonics in sound that if you wipe out, it makes things sound funny... even human voices.
Now onto your arguement.
It's mathematically impossible to represent analog waves in binary without making assumptions that hurt audio unless you over sample.
1) What if you want a triangle wave instead of a sine wave in your example? What about any wave that is skewed like a lot of audio is, and that defines what an instrument sounds like. A violin doesn't make a perfect sine wave when playing a note, and thus the harmonics aren't going to be the same.
2) Phase shifting the wave to fit is the WORST thing you could do to harmonics, which is what you're getting at 20Khz. I would rather have a power loss than a phase shift, because you can adjust for power loss better with an equilizer. In your model with random frequency shifts, there is no way short of DSP the likes of which would require 500Mhz of CPU power to attempt to correct for. The best thing you may be able to do is try to do a PLL on the signal on a lower frequency and recreate the harmonic by hand.
3) Wavelets would be great, but I don't think you want to throw that kinda power at the system rather than clocking it up. Maybe when an OK DSP that supports wavelets becomes cheaper than an ADC running at 192Khz and 16-24 bit audio, things will be different. As for right now, wavelets are practically theoretical. There aren't enough PhD's in math and engineering not working on military projects to spend time developing wavelets for civilian use.
Nyquist's theorem is pretty much trash.
1) It assumes that you can take a measurement wherever you feel instead of where the clock signals. 2) It assumes that the wave is a sine wave.
1 is unrealistic, and 2 is just plain wrong. I bet you can hear a difference between a sine, triangle, and square wave at 20Khz. I gaurantee you can here a difference when it's phase shifted on top of another lower frequency wave of the same note.
Tubes generally have a flatter curve when comparing amps out to signal voltage, but MOSFETs have a flatter RMS Watts out compared to RMS signal level. Basically, MOSFETs screw up the wave form more than tubes, but manage to preserve the loudness at various frequencies better.
I would rather take the one that can be fixed with an equalizer.:)
Where transistors really rule though is low power usage. A class A tube amp will keep you warm at night without even actually making noise. We need better transistors, but I'm not saying we need tubes everywhere.
What you are saying about needing twice the sampling rate is complete BS. Between that remark and the tube vs MOSFET remark, I can tell you care very little about the wave form.
If I tried to make a 20khz sound with 40khz sampling, I wouldn't hear a thing. Take two samples of one wave equidistant, and you get the middle and the beginning of the wave, which are always the same value. At 4X the sampling, you get a saw wave (or worse, a muffled trapazoid if you phase shift 45 deg). So, if you do 20Khz at 80Khz, you're still screwed. How many points do you need on a wave to make it smooth? I would say at least 8 at high frequencies (and that has a chance of only getting you about 66% of the power). That's about 160Khz for 20Khz sound.
I hate that someone actually thought the whole 2X the audible range was good enough to begin with. You may not hear a difference, but I can. If you don't, check the frequency response of your speakers.
If you want to calculate how many samples it takes to get >90% power, you should calculate the distance on the wave that is 90% power, then divide the length of the full wave by that distance, then multiply by 20Khz. So, here's a trusty sine table for you already measured in percentage of wave:.15 :.81.18 :.90.20 :.95.25 : 1.30 :.95.32 :.90.35 :.81.32-.18=.14 1/.14 = 7.14 20KHz*7.14=143KHz
This isn't RMS calibrated, but so what.
192KHz:/20KHz=9.6 2pi/9.6=.65 radians sin(pi/2-pi/9.6)= 94.69% power output. Basically, it's the sine of half the distance away from the peak to the furthest point out. Why is is it not the average? If you take the average, then you are forgetting that you will miss the right side of the wave completely. The only case better is sometimes when you hit the exact peek.
Also, you have to consider that this is going to create distortion too. Consider that the resonance of 20KHz with the actual output level, since it varies around the 94% mark.
If they are going through that much work, I wouldn't be suprised if there wasn't a seperate card with the DAC that you put in a slot and run cables to. It's been done before, just not for this purpose.
That said, I actually think 32bit audio may be at least 8 bits overkill. I'm all for 192Khz, because we can actually hear a difference in the resolution of the wave. 16bit audio allowed for 64K levels that were smoothed between. Most audio is pretty smooth sounding, and I doubt you can hear any difference between 16 and 32 bit unless you crank the volumn up to a level that could damage your hearing.
Also, 32bit DACs are practically impossible to buy last time I checked. A full 16bit DAC is pretty expensive relatively and it's exponentially more complicated with each bit to build a proper DAC. I'm expecting a lot of shortcuts. A 32bit ADC for recording is prohibitively expensive, so I gaurantee you won't be doing any 32 bit recording any time soon on a PC.
Basically, the 32bit idea is dead in the water. The machine will be long gone before any audio is distributed that takes advantage of it. You probably can't use it for mixing because you probably won't be able to record at 32bit. It's also going to be more expensive in components. Speakers aren't going to be accurate enough to 32bits of resolution. They may shoot for 24 bit, because you can get an OK DAC and ADC for working with 24 bits, but it'll still cost.
The 192Khz thing is awesome. Right now, you can get 48Khz out of some consumer cards, but 192 would be excellent. Maybe we'll get digital audio up to proffesional quality some day. Right now if you go get a recording from a studio, you get tape (unless you can't afford it). All professional audio equipment is not only analog end-to-end, it's also usually tube based. The average transistor is pure sewage, and even MOSFETs are lacking. There's gotta be a lot more R&D into just transistors before we have professional grade audio going anywhere near digital. This is still going to be helpful to the end user that likes music, but we are still a long way off from having no audible differences. Amazingly enough, I think speaker technology has advanced more over the last decade than digital audio.
If you need another SUN system though, and you have a Solaris admin on sight, it can still be cheaper than getting different versions of your software for the hetrogenious environment, that the admin isn't used to, out to the different clients and keeping them in sync.
I agree, SUN hardware has basically been going the way of COBOL. Whenever a company gets the oportunity, they ditch it. A few people still end up getting into the market though, so I don't think they are loosing business, I just think they aren't keeping up the percentage of the market that they had.
I think the future is going to be clusters, and we're all going to have to find a way to divide the problem. Most business software is about moving data more than calculating still yet. Most business computing also deals in a lot of small peices of data that they process, so usually it scales easily so long as your DBMS scales with it. Data partitioning makes life better.
Mark and sweep was used for quite a long time in Java. Thanks for the information.
I don't know when or how, but since this whole VM thing really has caught on so well, I really do believe someone will solve the whole realtime + gc conflict. It could just go down to special hardware for running garbage collected systems. IBM may have some magic left to put in their servers to dominate the Java world. If and when business begins to demand realtime processing, I think we'll see some solution. I wonder what would be entailed in a temporary object heap that you try to keep clean, so you can gaurantee realtime processing under specific circumstances (That you actually do have X Meg free, and that you will never need to allocate more than X Meg at once without a break of at least Y ms to clean some heaps where X is temporary heap size and Y is the amount of time it takes to clean main heap and move data from X into long-lived heap.). I don't even know what kind of gaurantees you can make with an RTOS when it comes to scarce memory though. Sometimes it's just not possible to run, and a lot of times in software written in C it's going to be less likely because of wasted internal fragmentation because you have to have at least 4K chunks, where Java will allocate whatever you need.
I still think some crazy man will make a VM that is just faster, better, and stronger than compiled native code. There's always going to be something you could do in native code, but it will take you twice as long.
I heard that story before, and it was LISP in the version I heard, not Java. Since it was AI, it would make more sense too. Then again, the story I heard was that they were trying to catch the ball.
Also, just to beat the dead horse, GC is incremental these days, and so long as you actually have free memory, it's not going to hang the application. It may slow it down a little on object creation when you are low on memory.
I also don't think the rover runs Java, even though it would work just fine. Anyone who's used Lejos can tell you that it works just fine for just about anything you could need to program.
Someone said something about power requirements and performance, but considering a lot of people use Basic in embedded systems, I tend to take those arguements as being a bit biased without actually any real knowledge of whats going on.
Actually, MS breaks compatibility with old software all the time:) I'm sure they'll do so again in Windows 2003, and then everyone will probably just go.Net then. Also MS has been known to run old code in compatibility layers, that could be VM like in the future.
Given MS history of security implementations, I'm sure someone will find a way to sign a virus or get one through email. Implemented properly though, it would be hard, because whoever's key signed it will be revoked and virus will be stopped dead in it's tracks. No more ongoing wars with viruses like Blaster.
They're steps in the right direction, and they will help. How much help it will be only time can tell. I'm just frustrated that a lot of Linux developers seem to be stuck in 1980.
I'm just going to respond to the common themes in one place, I'm not picking on you:)
The arguements seem to be: Auto updating can break things? a) If Linux had a good API standard it wouldn't be possible. The kind that come with an application development platform built on top of a kernel. The kind that usually are named after caffeinated beverages or top level domains. Python could become an excellent API, but some people are going to want better performance. If you go Java, you'll have to go Kaffe, which is still young..Net/Mono is still a little risky. I know what the solution is, but I don't know how far away it is. A standard, safe platform for development is going to be neccisary if Linux is actually going to go desktop. One could be built in C, but that would be putting us behind everyone else who has had a C platform for years. We need a VM platform as well. As of right now Java is the only thing that could actually work in terms of performance. b) Even in the case of using C, there are enough projects running at Debian that they can test the API enough to know it's not going to break anything in Stable. It's not a big deal to offload the testing to distros, infact, it's part of their job. A package that breaks anything should NOT make it out to stable ever. If it does, its a rarity, and you can just go roll back some updates which should take about as much time. c) If this is going to be the year of the desktop, we have to start acting like it. End users are too stupid to update their own systems. Auto updating should come on by default, and then we as smart admins should turn it off on servers. Expecting an idiot to enable it isn't going to happen. Maybe if you made it default on in the installation scripts, that could work, but it'll have to default on, because they don't read the EULA, you think they are going to read the actual questions?
Some people say that MD5 sums are good enough "code signing". They aren't unless the kernel checks them when loading a program and refuses to load it if it came from a root kit. Signing would certainly be easier than downloading MD5's from the original site over an SSL connection every time you run a program. We still have problems with trojan utilities on Linux that MD5 is really not going to fix.
There are a lot of IDE's for those languages, most of them written in the language. Python, I know, has a ton of good IDE's. PyPE is one of my favorites.
One person argued that you have control in C over bugs in the environment. You have no more control over bugs/buffer overflows in C as any other language. You do have to use libraries, and Python is open source. It's better that security was handled by only a couple projects instead of every single project.
I would be very much interested in volunteering in making a secure open-source framework for applications if the average open-source crazy man would actually use it. It's very much needed. I envision an RPC with SSH encryption and single sign-on support with trusted servers. You could have functions available in SOAP over HTTPS simultaneously and be able to make good, distributed, secure software with both proprietary and open RPC standards and top of the line security. Client applications can generally be trusted to run in C, thus the whole system will appear to perform just as well, I think.
I have to give MS two thumbs up. They now have automatic updates pushed to clients. They also have the Server tools to cache the updates locally for networks, and push them from there so you can hold updates back if they break some internal software.
MS is also working on more secure technologies like.Net. In the future, code written for windows will be written in.Net by default, and buffer overflows will pretty much go away.
MS is working on code signing at every level of the system. This means no more boot viruses, no more trojans.
MS is still lacking on speed to update. The RPC bug was on the streets long enough for exploits to be written BEFORE they got even the smallest patch out. The big worms came after they did get the patch out, but people weren't updating.
Where does Linux stand in all of this?
Updates are usually still handled manually with apt-get update/upgrade. RedHat has live notification, but it's still done manually for the most part, which slows down the process. There are wasy of caching apt packages for internal use by making your own apt-source, but they can be difficult to implement. You can do similar things with RedHat, but there isn't a lot of work being done in this area.
Open Source developers still hug C and hate most anything running in any other safer languages because of performance. Despite it actually costing more man hours to manually go out and install new versions of SSH, bind, sendmail, etc. every 3 months, for some odd reason open source developers value cpu clock cycles on a machine that sits idle 99% of the time more than an actual person that can hardly find 5 minutes, and usually admins so many computers it turns into an all-nighter.
Open Source people see code signing as a way to enact DRM and are fighting it.
Open Source releases updates within minutes of being aware of prossible security problems, sometimes it can take an hour or a day on less critical projects, but for the most part updates are very quick.
I see progress in MS land, but Open Source people are fighting the future, and are living in status quo. There's no reason why 99% of the daemons out there couldn't be written in Python or Java (with Kaffe even). There's no real reason to fight TCP yet.
Slashdot Mirror
It's possible they could counter sue. Other than that, there are court costs. You should always consult a lawyer, so unless you have a lawyer friend or no real assets that they could claim, then it's probably not realistic. I wasn't really serious. :)
If you really want to take them to court, you can sue them for damages as well as legal costs. It would require some time and money... The likes of which you probably don't want to invest.
If you want to DoS SCO to shut them up... DoS their lawyers. Go to your local courthouse and file a civil suit against them complaining that they are harming your Linux business with their libelous claims. That'll drain their funds quicker than a DoSing virus, even if you loose.
For one, the TLB has to be bigger for 64bit addresses.
Secondly, even RAM running at 333MHz can only switch pages at about 111MHz optimally. Everytime you leave a 4K barrier, you might as well put 20 NOP's in your code.
You're going to have some cache misses... It's best if you try to make them only have to do a row select on RAM. If you have huge data structures that warrent 64bit addressing, you aren't going to have as much cache to help prevent this. In fact, you should be flipping pages almost all the time.
When allocating memory for objects, you should allocate it all together, and you need to set a maximum size for your object, then use relative addressing.
The neat thing about VMs is that they will do this for you. Some defragment your memory periodically. They manage all your pointers, so they know what size they should be. VMs generally allocate contiguous heaps of memory to avoid paging when possible too. There are a lot of advantages to VM software, that until recently haven't been leveraged enough to make it show on benchmarks.
You can claim it is a compromise, if you want, but it is not both an advantage and a disadvantage. Parts of it are to your advantage, others may be to your disadvantage, but on a whole it can be one, the other, or neither. That's like saying that a=1+2i and b=2+1i then claiming that ab because different parts are greater. On a whole they are equal in magnatude, abs(a)=abs(b). They just go in different directions.
I hate it when slashdot tries to parse as html in "plain old text" mode.
I absolutely hate when the techies requesting the job have a typo in an acronym, and you get a phone interview. "I didn't see on your resume if you had an EBJ experience." They don't understand that EJB was what was meant, and that discredits your experience. Someone will eventually say, "Yes, I have 2 years of EBJ experience" and when they get through HR, they'll get the job because they just made you look like an ass that didn't know what "EBJ" was.
Another problem I have is requiring more than a year of experience in anything. If you can't learn it by using it for a full year, you would have been fired about two months into the last job.
I really enjoy working with technical recruiters more because they actually know what the hell they are talking about most of the time, and they work through HR, so there really aren't any problems like that.
That said, I've had probably 20 phone interviews, a good percentage saying they were going to try to set up an interview with tech staff. So far, only one of them has come through, and they are a recruiter. I really just think there is a shortage of actual jobs. I've customized my resume for positions before and received no response at all. Needless to say, I don't bother with that company any more considering I put forth hours of effort, and they didn't have 30 seconds to say "No, we're sorry, we can't use you. If something comes up, we'll give you a call." then ignore me. I figured they have an email template for that kind of thing. An auto-responder would show more respect. Bad peer reviews of companies go a long way too. I have neglected to apply to a few companies because I've been told of their practices. You would think that the HR department's existence is to prevent this situation.
No, they'll just remove whatever has been shown to be offending code, replace it, and move on like SCO never existed.
BSD doesn't even have a GPL license, which will offend some people.
BSD is Darl's next target.
I wished it meant switching kernels, because then it would be everyone working on the HURD, which is a designed system, not an ad-hoc bundle of code migrating to a design. Unfortunately, designed systems take longer to make, and thus are abandoned as being inferior because of limited insight of the general population. Most people just want something that works, some of us want something that works, is easily extendable, has a consistent API, and is scalable.
Before anyone replies with some nonsense about HURD/Microkernels not being scalabale because of context switches, please do shoot yourself in the head for confusing speed and scalability. As for those going to reply about Mosix extensions to Linux, please slap yourself for not reading what I said about Linux evolving toward design. With the proper support, the HURD would probably have had better functionality than Mosix about a decade ago.
I gaurantee you that you'll have more data in the class than the pointer to it always... or else you're just being really stupid. I'm also assuming that most people are going to have long addresses and many phone numbers. If you add in the other fields to those objects, I think you're looking at your data being anywhere from 10-30% pointers even in a 64bit world.
Most pointers are code relative jumps IE function addresses. Most people should probably look more for data segmentation than absolute addresses anyhow, especially on embedded devices where memory tends to be much slower. Switch pages only when you need to. Most 64bit addresses are only going to need maybe 4-8 bits above the 32bit mark... even for VM. It would probably be better to store 8bit pointers then combine them with a 32bit offset to generate the 64bit absolute address. I can't think of many application that would benefit from the terabyte of address space this would give though. You're application will likely not need that for memory addressing.
Like I said in a previous post, there are ways to work around it for huge databases too. 4K disk blocks * 2^32 = 16TB database. I don't know of any database that has crossed the terabyte threshold yet, but it's very likely there are some... On the kinds of machines that you would use databases that large, it's still going to be better to increase the disk block size than the 32bit pointers. It's not uncommon to have 64K clusters on desktop machines these days... Thats 256TB.
Ummm... I beg to differ on the reasons...
Most 64/32bit hybrid machines probably just split the arithmatic/logic units in half (just takes a single wire to connect them anyhow). Having an extra ALU around will surely push more 32bit numbers through the pipe. It's not going be as fast as a 64bit optimized application would gain from having the combined operations should it need them though.
I'm beginning to wonder these days how much CPU speed even matters though. We have larger applications that can't fit in cache, page switching from RAM that isn't anywhere near the speeds of the CPU, and hard drives that are only 40MB/s on a good day/sector, with latency averaging around 5-6ms. CPU is the least of my worries. As long as the hard disk is being utilized properly, you'll probably not see significant differences between processor speeds. I'm a firm believer that people think that 500MHz is slow because the hard drive in the machine was too slow. Unless you are running photoshop, SETI, Raytracing, etc., you probably wouldn't notice if I replaced your 3GHz processor with a 1GHz.
I think the cache arguement is complete BS. It appears it would be true, but not really. Most pointers are created and controlled by the compiler, and they are going to be relative 90% of the time. That's why relative addressing was invented. So, you get an extra 4 bytes stuffed into your cache on the relatively rare occurance that one of your 8 byte pointers are being used. In this 8 byte pointer, I'm just going to assume that you aren't idiot enough to be accessing memory in the same page most of the time. I really think that the page switching of the RAM to access the data at the other end of the pointer is going to be the greatest overhead. Normal cache misses in a 64bit addressing scheme should be exponentially more than a 32bit, if you really needed the 64bit.
So while you may have a caching problem, I think it's going to be because of accessing more data rather than the 4 bytes extra on some pointers.
Now if you're using disk based data structures, you better be using 64bit. I could make an exception if you used a 32bit number to address the cluster, then a 16bit number to access the actual data in the cluster, if required. A good DB server would do well to use 32bit cluster numbers to save index size, then scan the loaded cluster for the record. AFAIK, no one has been clever enough to do this, but I'm not privy to the internal structures of a lot of DBMSs. And this would matter a lot, because you could fit much more of the index into memory, and have much less data to read on the drive. Throwing away CPU cycles and memory for more compact disk data is a common practice.
"one of the waste pipes burst through the ceiling onto the VAX."
I was wrong... There is a god, and he still smites the wretched.
Then from the obvious observation that you can tell a sine and a triangle wave apart, you should come to the obvious conclusion that in your model a human can detect signals up to about 100KHz. I prefer to think of it more as:
There are two theories for you:
1) Recording devices don't clamp signals exactly at the desired frequency, so signals >22Khz that obviously do exist are interfering with the 22KHz signals in a way that distorts the wave when you try reconstruct it.
This theory doesn't hold because experiments involving humans and the higher frequencies showed that even with analog equipment, humans can detect the difference. This theory does show that Nyquist theory doesn't apply, because the Nyquist theory states that there must not exist any frequency signal above the one you are trying to capture.
2) Fourier theorem doesn't apply to human hearing because human's don't hear frequencies at different levels, they hear the shape (for lack of a better word) of the wave as well, so they can detect the frequencies up to 100KHz, but not hear them.
This is the place where you were supposed to introject a counter theory, not attack my knowledge of Nyquist and Fourier theories. They are both mathematical models. Recording devices sampling back at the same rate are not going to tell a difference because they rely on those same theories. Human's aren't going to like it any more than sticking the wire from the DAC on their tounge because the principals, as of yet, have not involved human perception. At least my monitor's mathematical model took into account the frequency response of my eye. I grow very tired of people testing the principals of their design with systems that assume the principals of their design.
Nyquist and Fourier theories are all nice and good when they are applied to the field they were intended, neither of which are human perception of audio. Nyquist theory applies very well to networks, and fourier works great at seperating and recombining waves. I doubt very much that you could apply fourier transforms in a way that you would understand speech, because that's not the way humans hear.
I'm really tired of this arguement, so I'll just point you to a site that says it much better than I want to take the time to say.
Ultrasonics
As you'll read, there has been research done, and it is noticable to chop off frequencies above 22KHz. Granted a single wave is not going to show the difference, but we more than likely detect that waves effects on other waves.
That's great! It's pretty much perfect. I hadn't looked at the new Creative cards. I've been using Live! for about 5 or more years now, and while I'm happy with it, analog has still been my friend.
I'll have to look at it's recording capabilities. They usually have a lot of options for that kind of thing.
You can not distinguish between sine and triangle waves with only 2 points per wave. You pick two points equidistant, and I'll draw a phase shifted sign wave through them. That is BAD! There is not enough information to properly construct a wave with only two points. There is only enough information to construct a sine wave if you already know the wave is a sine wave. I'm not disputing that if you can accurately represent 20KHz that you would have a problem representing 19KHz overlayed on it.
I gaurantee I know more about DSP than either of you know about music and audio equipment. I once was under the delusion that with enough DSP I could recreate an exact sounding digital implementation of a tube using transistors. I was doing this to digitally record my guitar. The reality of the situation set in while researching ADC (It's very expensive to even get a logarithmic comparitive ADC that can follow 192KHz at 16 bit accuracy (18bit internal)). And transistor charicteristics are more skewed than tubes, so it would take a greatter than 16bit accurate sample in order to map to the appropriate position without making generalizations about the shape of waves. I've seen several waves under O-Scope, and know quite well that they are not sine waves. I wrote some wave files with different wave forms and piped them through audio out, and it's more than noticable at any frequency, just like clipping a wave.
Even after you consider all this, you also have to compensate for speaker response, and microphone/pickup recording characteristics. Pickups on a guitar don't match so great with most audio systems, and you need to work on impedance mismatches.
To actually make a good digital guitar, I was looking at pretty much a PhD level project. In fact, I'm saving the project for just that. It combines extensive Math, CS, Art, EE, and a bit of physics. I very much plan on running both through an analog comparator where the speaker should be (with some phase and volume tuning of course) just to see how close it is. If I get 90% accuracy I'll consider the project a success.
I don't know where your assumption that at highest frequency response of a human ear, you can't tell the difference in waveform comes from, but I assume it comes from you piping sound back into a recording device that has a sampling rate. Yeah, you can reconstruct it so that a sampling device can't tell a difference, but we humans don't sample. Our hearing is a very much more complicated than that. Most people don't know that we use the delay of sound from one ear to another to determine the position of a sound's source. We can distinguish a wave from front or behind, with only two ears in a lot of cases. Feeling is also incorperated into our hearing as much as smell is to tasting.
If you stop making assumptions about human hearing from a DSP perspective, maybe you'll start to see yourself.
I learned Python and Zope both in two weeks, and I was quite able to make a database driven web-site in those two weeks while learning, that took me a month to make in PHP, and I had used PHP quite a bit in the past.
:) Remember, the limiting factor for dynamic web sites is bandwidth. The second limiting factor is your DB/hard disk.
Comparing Zope to PHP, I think most people will come to the conclusion that not only is Zope easier to develop for, but also it's easier to maintain since it gently encourages you to move your data-access/queries into a seperate space.
I've had a Zope server running without a single hickup for about 2 months now. I'm also a J2EE guy, and since then, I've had JBoss bail out at least twice on some servers. It's very stable.
If you don't like zope, it'll be because the documentation is skimpy, or you'll be writting dynamic web sites in ASM just to get the last bit of performance out of it even though the data pipe is already satuerated
You're the highest ranking responder, so you get picked on :)
Just to answer other people in the thread about why you want the full audible range, there are harmonics in sound that if you wipe out, it makes things sound funny... even human voices.
Now onto your arguement.
It's mathematically impossible to represent analog waves in binary without making assumptions that hurt audio unless you over sample.
1) What if you want a triangle wave instead of a sine wave in your example? What about any wave that is skewed like a lot of audio is, and that defines what an instrument sounds like. A violin doesn't make a perfect sine wave when playing a note, and thus the harmonics aren't going to be the same.
2) Phase shifting the wave to fit is the WORST thing you could do to harmonics, which is what you're getting at 20Khz. I would rather have a power loss than a phase shift, because you can adjust for power loss better with an equilizer. In your model with random frequency shifts, there is no way short of DSP the likes of which would require 500Mhz of CPU power to attempt to correct for. The best thing you may be able to do is try to do a PLL on the signal on a lower frequency and recreate the harmonic by hand.
3) Wavelets would be great, but I don't think you want to throw that kinda power at the system rather than clocking it up. Maybe when an OK DSP that supports wavelets becomes cheaper than an ADC running at 192Khz and 16-24 bit audio, things will be different. As for right now, wavelets are practically theoretical. There aren't enough PhD's in math and engineering not working on military projects to spend time developing wavelets for civilian use.
Nyquist's theorem is pretty much trash.
1) It assumes that you can take a measurement wherever you feel instead of where the clock signals.
2) It assumes that the wave is a sine wave.
1 is unrealistic, and 2 is just plain wrong. I bet you can hear a difference between a sine, triangle, and square wave at 20Khz. I gaurantee you can here a difference when it's phase shifted on top of another lower frequency wave of the same note.
So, it's more than a filtering issue.
They must be using double precision floating point? :)
Tubes generally have a flatter curve when comparing amps out to signal voltage, but MOSFETs have a flatter RMS Watts out compared to RMS signal level. Basically, MOSFETs screw up the wave form more than tubes, but manage to preserve the loudness at various frequencies better.
:)
.15 : .81 .18 : .90 .20 : .95 .25 : 1 .30 : .95 .32 : .90 .35 : .81 .32-.18=.14
/20KHz=9.6
I would rather take the one that can be fixed with an equalizer.
Where transistors really rule though is low power usage. A class A tube amp will keep you warm at night without even actually making noise. We need better transistors, but I'm not saying we need tubes everywhere.
What you are saying about needing twice the sampling rate is complete BS. Between that remark and the tube vs MOSFET remark, I can tell you care very little about the wave form.
If I tried to make a 20khz sound with 40khz sampling, I wouldn't hear a thing. Take two samples of one wave equidistant, and you get the middle and the beginning of the wave, which are always the same value. At 4X the sampling, you get a saw wave (or worse, a muffled trapazoid if you phase shift 45 deg). So, if you do 20Khz at 80Khz, you're still screwed. How many points do you need on a wave to make it smooth? I would say at least 8 at high frequencies (and that has a chance of only getting you about 66% of the power). That's about 160Khz for 20Khz sound.
I hate that someone actually thought the whole 2X the audible range was good enough to begin with. You may not hear a difference, but I can. If you don't, check the frequency response of your speakers.
If you want to calculate how many samples it takes to get >90% power, you should calculate the distance on the wave that is 90% power, then divide the length of the full wave by that distance, then multiply by 20Khz. So, here's a trusty sine table for you already measured in percentage of wave:
1/.14 = 7.14
20KHz*7.14=143KHz
This isn't RMS calibrated, but so what.
192KHz:
2pi/9.6=.65 radians
sin(pi/2-pi/9.6)= 94.69% power output.
Basically, it's the sine of half the distance away from the peak to the furthest point out. Why is is it not the average? If you take the average, then you are forgetting that you will miss the right side of the wave completely. The only case better is sometimes when you hit the exact peek.
Also, you have to consider that this is going to create distortion too. Consider that the resonance of 20KHz with the actual output level, since it varies around the 94% mark.
If they are going through that much work, I wouldn't be suprised if there wasn't a seperate card with the DAC that you put in a slot and run cables to. It's been done before, just not for this purpose.
That said, I actually think 32bit audio may be at least 8 bits overkill. I'm all for 192Khz, because we can actually hear a difference in the resolution of the wave. 16bit audio allowed for 64K levels that were smoothed between. Most audio is pretty smooth sounding, and I doubt you can hear any difference between 16 and 32 bit unless you crank the volumn up to a level that could damage your hearing.
Also, 32bit DACs are practically impossible to buy last time I checked. A full 16bit DAC is pretty expensive relatively and it's exponentially more complicated with each bit to build a proper DAC. I'm expecting a lot of shortcuts. A 32bit ADC for recording is prohibitively expensive, so I gaurantee you won't be doing any 32 bit recording any time soon on a PC.
Basically, the 32bit idea is dead in the water. The machine will be long gone before any audio is distributed that takes advantage of it. You probably can't use it for mixing because you probably won't be able to record at 32bit. It's also going to be more expensive in components. Speakers aren't going to be accurate enough to 32bits of resolution. They may shoot for 24 bit, because you can get an OK DAC and ADC for working with 24 bits, but it'll still cost.
The 192Khz thing is awesome. Right now, you can get 48Khz out of some consumer cards, but 192 would be excellent. Maybe we'll get digital audio up to proffesional quality some day. Right now if you go get a recording from a studio, you get tape (unless you can't afford it). All professional audio equipment is not only analog end-to-end, it's also usually tube based. The average transistor is pure sewage, and even MOSFETs are lacking. There's gotta be a lot more R&D into just transistors before we have professional grade audio going anywhere near digital. This is still going to be helpful to the end user that likes music, but we are still a long way off from having no audible differences. Amazingly enough, I think speaker technology has advanced more over the last decade than digital audio.
If you need another SUN system though, and you have a Solaris admin on sight, it can still be cheaper than getting different versions of your software for the hetrogenious environment, that the admin isn't used to, out to the different clients and keeping them in sync.
I agree, SUN hardware has basically been going the way of COBOL. Whenever a company gets the oportunity, they ditch it. A few people still end up getting into the market though, so I don't think they are loosing business, I just think they aren't keeping up the percentage of the market that they had.
I think the future is going to be clusters, and we're all going to have to find a way to divide the problem. Most business software is about moving data more than calculating still yet. Most business computing also deals in a lot of small peices of data that they process, so usually it scales easily so long as your DBMS scales with it. Data partitioning makes life better.
Mark and sweep was used for quite a long time in Java. Thanks for the information.
I don't know when or how, but since this whole VM thing really has caught on so well, I really do believe someone will solve the whole realtime + gc conflict. It could just go down to special hardware for running garbage collected systems. IBM may have some magic left to put in their servers to dominate the Java world. If and when business begins to demand realtime processing, I think we'll see some solution. I wonder what would be entailed in a temporary object heap that you try to keep clean, so you can gaurantee realtime processing under specific circumstances (That you actually do have X Meg free, and that you will never need to allocate more than X Meg at once without a break of at least Y ms to clean some heaps where X is temporary heap size and Y is the amount of time it takes to clean main heap and move data from X into long-lived heap.). I don't even know what kind of gaurantees you can make with an RTOS when it comes to scarce memory though. Sometimes it's just not possible to run, and a lot of times in software written in C it's going to be less likely because of wasted internal fragmentation because you have to have at least 4K chunks, where Java will allocate whatever you need.
I still think some crazy man will make a VM that is just faster, better, and stronger than compiled native code. There's always going to be something you could do in native code, but it will take you twice as long.
I know you aren't that serious, but ...
I heard that story before, and it was LISP in the version I heard, not Java. Since it was AI, it would make more sense too. Then again, the story I heard was that they were trying to catch the ball.
Also, just to beat the dead horse, GC is incremental these days, and so long as you actually have free memory, it's not going to hang the application. It may slow it down a little on object creation when you are low on memory.
I also don't think the rover runs Java, even though it would work just fine. Anyone who's used Lejos can tell you that it works just fine for just about anything you could need to program.
Someone said something about power requirements and performance, but considering a lot of people use Basic in embedded systems, I tend to take those arguements as being a bit biased without actually any real knowledge of whats going on.
Actually, MS breaks compatibility with old software all the time :) I'm sure they'll do so again in Windows 2003, and then everyone will probably just go .Net then. Also MS has been known to run old code in compatibility layers, that could be VM like in the future.
Given MS history of security implementations, I'm sure someone will find a way to sign a virus or get one through email. Implemented properly though, it would be hard, because whoever's key signed it will be revoked and virus will be stopped dead in it's tracks. No more ongoing wars with viruses like Blaster.
They're steps in the right direction, and they will help. How much help it will be only time can tell. I'm just frustrated that a lot of Linux developers seem to be stuck in 1980.
I'm just going to respond to the common themes in one place, I'm not picking on you :)
.Net/Mono is still a little risky. I know what the solution is, but I don't know how far away it is. A standard, safe platform for development is going to be neccisary if Linux is actually going to go desktop. One could be built in C, but that would be putting us behind everyone else who has had a C platform for years. We need a VM platform as well. As of right now Java is the only thing that could actually work in terms of performance.
The arguements seem to be:
Auto updating can break things?
a) If Linux had a good API standard it wouldn't be possible. The kind that come with an application development platform built on top of a kernel. The kind that usually are named after caffeinated beverages or top level domains. Python could become an excellent API, but some people are going to want better performance. If you go Java, you'll have to go Kaffe, which is still young.
b) Even in the case of using C, there are enough projects running at Debian that they can test the API enough to know it's not going to break anything in Stable. It's not a big deal to offload the testing to distros, infact, it's part of their job. A package that breaks anything should NOT make it out to stable ever. If it does, its a rarity, and you can just go roll back some updates which should take about as much time.
c) If this is going to be the year of the desktop, we have to start acting like it. End users are too stupid to update their own systems. Auto updating should come on by default, and then we as smart admins should turn it off on servers. Expecting an idiot to enable it isn't going to happen. Maybe if you made it default on in the installation scripts, that could work, but it'll have to default on, because they don't read the EULA, you think they are going to read the actual questions?
Some people say that MD5 sums are good enough "code signing". They aren't unless the kernel checks them when loading a program and refuses to load it if it came from a root kit. Signing would certainly be easier than downloading MD5's from the original site over an SSL connection every time you run a program. We still have problems with trojan utilities on Linux that MD5 is really not going to fix.
There are a lot of IDE's for those languages, most of them written in the language. Python, I know, has a ton of good IDE's. PyPE is one of my favorites.
One person argued that you have control in C over bugs in the environment. You have no more control over bugs/buffer overflows in C as any other language. You do have to use libraries, and Python is open source. It's better that security was handled by only a couple projects instead of every single project.
I would be very much interested in volunteering in making a secure open-source framework for applications if the average open-source crazy man would actually use it. It's very much needed. I envision an RPC with SSH encryption and single sign-on support with trusted servers. You could have functions available in SOAP over HTTPS simultaneously and be able to make good, distributed, secure software with both proprietary and open RPC standards and top of the line security. Client applications can generally be trusted to run in C, thus the whole system will appear to perform just as well, I think.
I have to give MS two thumbs up. They now have automatic updates pushed to clients. They also have the Server tools to cache the updates locally for networks, and push them from there so you can hold updates back if they break some internal software.
.Net. In the future, code written for windows will be written in .Net by default, and buffer overflows will pretty much go away.
MS is also working on more secure technologies like
MS is working on code signing at every level of the system. This means no more boot viruses, no more trojans.
MS is still lacking on speed to update. The RPC bug was on the streets long enough for exploits to be written BEFORE they got even the smallest patch out. The big worms came after they did get the patch out, but people weren't updating.
Where does Linux stand in all of this?
Updates are usually still handled manually with apt-get update/upgrade. RedHat has live notification, but it's still done manually for the most part, which slows down the process. There are wasy of caching apt packages for internal use by making your own apt-source, but they can be difficult to implement. You can do similar things with RedHat, but there isn't a lot of work being done in this area.
Open Source developers still hug C and hate most anything running in any other safer languages because of performance. Despite it actually costing more man hours to manually go out and install new versions of SSH, bind, sendmail, etc. every 3 months, for some odd reason open source developers value cpu clock cycles on a machine that sits idle 99% of the time more than an actual person that can hardly find 5 minutes, and usually admins so many computers it turns into an all-nighter.
Open Source people see code signing as a way to enact DRM and are fighting it.
Open Source releases updates within minutes of being aware of prossible security problems, sometimes it can take an hour or a day on less critical projects, but for the most part updates are very quick.
I see progress in MS land, but Open Source people are fighting the future, and are living in status quo. There's no reason why 99% of the daemons out there couldn't be written in Python or Java (with Kaffe even). There's no real reason to fight TCP yet.