> Sure, data is the important thing, but it's not impossible. I saw an apple 2 program that sent data to a PC's serial port by toggling the joystick port (one bit per port, four ports, I think) in a specific pattern over a custom cable that they provided a diagram of. You could always do a hex dump of the data and take a picture of each screen (automate it) and OCR it in...
Yes, it is quite possible for as long as you have access to the old hardware. As you point out correctly, it may require custom solutions, and what I was trying to point out is that it won't be a matter of 'just' dumping the data in a file in quite a few cases, because of what you say and because such hardware might not be that trivial to emulate correctly when it contains its own 'intelligence'.
I use a parallel port and a custom cable to connect an old Commodore 1541 to my PC, and an ieee-488 i/o card to connect a cbm sfd-1001 floppy drive, both for converting old media, but as always, it requires access to the old hardware ('intelligent floppy drives' in this case).
If access to the old hardware is relatively easy still then it saves a lot of hastle to just use the old hardware to run the software. Transfer solutions are still a rather good idea tho just in case you all of a sudden can no longer get the 'real' stuff and for backup purposes.
> Uh yes, the original poster is correct. There are *emulator* programs that use an ISO image file as the backend store to a complete CD-ROM interface emulation.
Rereading the original post I see this was indeed what the poster was refering to.
> Loopback mounts are not the ONLY thing you can do with disk images.
I never said so.
> Dickwads like yourself should take the time to consider that other posters might actually know something you don't.
Any reason you think you have to go calling names? (all the more funny since you prefer to stay anonymous). If you had taken a minute to read some of my other posts in this thread you'd see that I'm rather well aware of the concept of using a file together with an emulator to emulate both the media and the hardware, so typical case of pot and kettle I'd say.
Indeed. While this is usually not much of a problem when emulating a game system, it is a rather big problem when emulating more 'serious' systems where user data must be transfered to the emulator.
Well, I'd not encourage people to 'use' them for interactive use, yet I do run my mailserver on a VAX (running NetBSD, not OpenVMS btw). It is not fast, but it does not slow down easily either.
> Just to be clear... A single jail is limited to a single IP.
Unless you add unofficial (for now?) patches, true.
> So you need one unique IP for each Jail on a machine.
Not true. If you know what you are doing, 2 or more jails can share an IP. It is not advisable to do this because it gets very confusing very quickly, and since this is a security measure first of all, confusion for the admoin is really the last thing that you want.
That said, I currently use exactly such a setup (multiple jails sharign a single IP)
I suggest looking also at MAC and posix 1e implementations which exist (and have existed for quite soem time) on FreeBSD. jails are only one of the options.
> However, I think the Linux VServer people right now have a leg up on FreeBSD jails. I really like the idea of contexts 0 and 1, where 'killall -HUP named' does not result in all named's in jails be restarted and ps and top aren't cluttered with jailed processes.
Yep, that is a very nice idea, it is however seldom needed in practise. Why?
First of all, your 'host' environment should nto be used to run anything like named or such, rather, it should be used to start, stop and administer jails. If you do otherwise you break one of the most important defenses that jails can offer, the fact that a service runs in a 'protected' envrionment and cannot affect other environments on the same machine (at least not easily).
So it is cool to have, but in practise a rather minor feature. If I want to restart the named in a specific jail, typing 'jexec x killall -HUP named' in the host environment will do the job.
> The unify tool that finds same files and hardlinks them is really nice, and the disk space limits per context is great.
I'd say that this introduces a much bigger risk of a compromise spreading from one jail to another, so I rather doubt the wisdom of this approach.
Uh yes, like I said, one of the 2 alternatives you have is usign the old hardware to read the original media (and then you transfer it with whatever communications link you can manage). Point is, in order to do this, you need the old hardware, so this is no option whatsoever for replacing a machine that has given up, it is only an option when you do it beforehand.
> Yeah, but if you're going to build an I/O board and write custom emulation drivers, what's the cost compared to buying a new off-the-shelf system and tooling for the shop? Imagine the cost to hire contractors to tease apart the I/O specs on that old stuff just so they could then build a custom board and drivers to emulate the old software on a P4 or something. Compare that to reinvesting in a new system with tools. It's the new tooling which really costs. They've got an old system which works right now and they don't see the point in dumping a couple hundred grand or more to buy new stuff which does exactly what their old stuff still does perfectly well. Can't blame 'em. --M
Add to that that while a commercial solution might in itself notbe that extremely expensive, the changes to processes, and need for retraining, the resulting initial mistakes that will occur and so on cause quite a lot of extra costs.
> "Perfectly usable"... VAX... VMS... hahaha hhahaaahahhahaha. Good. Got that out of my system.
And while I hope it never happens to you, if you happen to get into hospital, there is quite some chance that your information will be registered on a.... VAX. that is right, an old, according to you obviously unusable VAX.
Next time you transfer some money, chances are quite good that your order will be processed by... again one of those unusable vaxen...
I suggest you delve a bit into the matter before laughing your ass off because this makes you look like someone who knows very little of what is being used.
> Some programs create virtual CD-ROM drives when you give them an (.iso) image of a CD-ROM. You could say that the said program is emulating a CD-ROM drive.
Uh no, that is not the same at all.
An ISO image contains a filesystem that can be mounted using a loopback device or similar. It in no way whatsoever tries to emulate a drive.
> Similarly, if you were emulating an old computer which has some kind of old disk drive, the drive itself would be emulated along with the rest of the computer. The data would be read from a file on the emulator's host's hard drive. Or maybe it could even read 3.5" disks that were formatted to hold no more data than the old disks. Either way, you woulnd't actually use one of the old disks.
Yes that works, but the problem is.. how do you get you old data in those files on your modern disk?
There is an aditional problem when you want to emulate devices like Commodore's 1541 and sfd 1001 drives, those are not like todays dumb floppy drives at all, they contain 1 or 2 (in case of the sfd 1001) cpus and you can run software on them. This feature was used quite extensively and you have to emulate that (which is done quite well by emulators like Vice for example)
> Honestly, is it such a big deal these days to dump your media onto a network store and -then- switch over to the emulated system?
Lets say you have some ancient system with 8" floppies and no networking whatsoever. How are you going to dump those media on your network then?
(and no, not a troll, there are plenty old systems out there that did not network well or not at all)
Media conversion is the one biggest problem of emulation unless you can still access the original hardware and somehow connect it to a modern machine (as is done for exampel with Commodore's 1541 floppy drive) or alternatively, you get some modern reader to read ancient media.
> Native binaries, blessed by Sun, available on FreeBSD. Yes I know I should complain to Sun. Yes I know it isn't FreeBSD's fault.
What is more, this is not only a problem for FreeBSD, but for each and every OS that SUN doesn't feel like 'blessing'. Many Linux distributions suffer from related licensing problems and cannot distribvute JAVA binaries either.
> But would it kill the FreeBSD developers to try to work up a relationship with Sun?
It is why there is a jdk 1.3 binary for FreeBSD. The relationship between FreeBSD developers and SUN isn't really the issue, SUN's attitude, resources and unusable source code license are the issue.
It is a major annoyance for anyone who wants to do anythign with JAVA whatsoever and who cannot pay SUN for the resources (when SUN doesn't feel like it has a reason to do it itself ofcourse)
> Java support is great. It's been there for a while. The problem (traditionally) has been that fbsd won't run an app container or ejb container (I was told with a shrug, that it "had to do with threading"). Has that been fixed yet?
First of all, the issue you talk about is with the prebuilt jdk 1.3 as sanctioned by SUN.
The issue is that it supports green threads only, not native threads.
My experience with a jdk 1.4.2 built from the source is that it does support this, and that anything I tried (and that is not just some applets, but also tomcat + servlets and jboss + servlets) work perfectly well.
> You're absolutely right. However there's a difference between the developer claiming "usable for most tasks. However [...]" and a developer claiming a version is a "Production" version.
And in all my experiences (I know, anecdotal evidence, but still, obne that is confirmed by many others who tried) 'usable for most tasks' in the FreeBSD world is a lot more usable then 'production ready' in the Windows world, and even in the Linux world.
> I find it rather funny that most of the responses claim that I haven't looked at the ports tree. On the contrary, I have kept very close tabs on the advancement of Java under FreeBSD. Back when our app ran under 1.1.8, we happily deployed FreeBSD. I will be first in line to deploy it again when the 1.4 JDK is bumped up to production-ready.
Have you actually tried it?
I have been running the FreeBSD native port for a long time, both server and client side, and it simply works, period.
There is an issue, that issue is Sun's source code licensing. That is however not a technical issue, and if you can build it, it is very usable for a production environment also.
> You don't get to call me moron, if you can't behave properly i have no wish to interact with you. I suggest you grow up.
I call you one if you behave like one. You are quite acting like the only thing that matters is what you think, while honestly you are clueless as to what you are talking about. Try to listen to people suggesting you might be mistaken instead of telling them off maybe.
> Newsflash: You don't get to decide what is correct. And "roaming profiles" are not desirable.
Let me tell you a little secret:
Microsoft specifies to quite a large extent how a Windows program should behave. The also made WIndows, so they determine what is considered correct behavior for a Windows program, not some clueless moron like you.
> When i switch between different windows installs or access program directories via network shares i'm screwed with such programs. No dice. I need programs which support the user not the megacorp
Maybe you should blame the design of windows for this and use another OS?
WHen you use windows, it really really really helps to at least observe the ideas that the people had who made it because they will determine how the thing works.
It is relevant how other windows programs work in this respect, you may have to maintain one computer with a few windows installs and have this problem, but virtually everyone else has to deal with multiple computers each with a single install and with user profiles stored in a central place.
If you'd make proper use of roaming profiles (provided your windows versions all support it) you would actually be able to share your configuration and settings between those multiple windows installs, but obviously you did not look enough into the matter to know this. Complainign is easier of course.
> It doesn't as it is. So that's easy enough.
I bet that is why peopel are using it.
> Boring on strawman argument there "I've never been mugged so nobody has been mugged". What you have or haven't seen isn't relevant.
Are you sayign here we should just ignore what you saw then?
> Actually no it isn't, since it doesn't support the Javascript 100% the user agent is irrelevant.
IE's document object model implementation is broken and needs a workaround which does not work in many other browsers (which do however properly implement the document object model)
It is IE that is broken according to the standards in this, not Firefox/Mozilla.
I suggest looking a bit more, usign your brains a bit more, and complaining a bit less.
IE is still not fully compatible with the DOM and DOM2 specs (getElementsByTagName('*') to give an example where IE messes up in each and every version).
IE provides some alternatives, and quite a few coders think that those are the only way to do thingws (document.all to name one example)
I'm sorry to say, but it is IE being broken here, and not with regards to Javascript so much as the document object model.
Slashdot Mirror
> Sure, data is the important thing, but it's not impossible. I saw an apple 2 program that sent data to a PC's serial port by toggling the joystick port (one bit per port, four ports, I think) in a specific pattern over a custom cable that they provided a diagram of. You could always do a hex dump of the data and take a picture of each screen (automate it) and OCR it in...
Yes, it is quite possible for as long as you have access to the old hardware. As you point out correctly, it may require custom solutions, and what I was trying to point out is that it won't be a matter of 'just' dumping the data in a file in quite a few cases, because of what you say and because such hardware might not be that trivial to emulate correctly when it contains its own 'intelligence'.
I use a parallel port and a custom cable to connect an old Commodore 1541 to my PC, and an ieee-488 i/o card to connect a cbm sfd-1001 floppy drive, both for converting old media, but as always, it requires access to the old hardware ('intelligent floppy drives' in this case).
If access to the old hardware is relatively easy still then it saves a lot of hastle to just use the old hardware to run the software. Transfer solutions are still a rather good idea tho just in case you all of a sudden can no longer get the 'real' stuff and for backup purposes.
If only the joke didn't seem to be reflected by reality. On another note, stick your head in that what you think you have to call me.
> Uh yes, the original poster is correct. There are *emulator* programs that use an ISO image file as the backend store to a complete CD-ROM interface emulation.
Rereading the original post I see this was indeed what the poster was refering to.
> Loopback mounts are not the ONLY thing you can do with disk images.
I never said so.
> Dickwads like yourself should take the time to consider that other posters might actually know something you don't.
Any reason you think you have to go calling names? (all the more funny since you prefer to stay anonymous). If you had taken a minute to read some of my other posts in this thread you'd see that I'm rather well aware of the concept of using a file together with an emulator to emulate both the media and the hardware, so typical case of pot and kettle I'd say.
Indeed. While this is usually not much of a problem when emulating a game system, it is a rather big problem when emulating more 'serious' systems where user data must be transfered to the emulator.
Well, I'd not encourage people to 'use' them for interactive use, yet I do run my mailserver on a VAX (running NetBSD, not OpenVMS btw). It is not fast, but it does not slow down easily either.
At any rate, usable != interactive use.
> Just to be clear... A single jail is limited to a single IP.
Unless you add unofficial (for now?) patches, true.
> So you need one unique IP for each Jail on a machine.
Not true. If you know what you are doing, 2 or more jails can share an IP. It is not advisable to do this because it gets very confusing very quickly, and since this is a security measure first of all, confusion for the admoin is really the last thing that you want.
That said, I currently use exactly such a setup (multiple jails sharign a single IP)
I suggest looking also at MAC and posix 1e implementations which exist (and have existed for quite soem time) on FreeBSD. jails are only one of the options.
> However, I think the Linux VServer people right now have a leg up on FreeBSD jails. I really like the idea of contexts 0 and 1, where 'killall -HUP named' does not result in all named's in jails be restarted and ps and top aren't cluttered with jailed processes.
Yep, that is a very nice idea, it is however seldom needed in practise. Why?
First of all, your 'host' environment should nto be used to run anything like named or such, rather, it should be used to start, stop and administer jails. If you do otherwise you break one of the most important defenses that jails can offer, the fact that a service runs in a 'protected' envrionment and cannot affect other environments on the same machine (at least not easily).
So it is cool to have, but in practise a rather minor feature. If I want to restart the named in a specific jail, typing 'jexec x killall -HUP named' in the host environment will do the job.
> The unify tool that finds same files and hardlinks them is really nice, and the disk space limits per context is great.
I'd say that this introduces a much bigger risk of a compromise spreading from one jail to another, so I rather doubt the wisdom of this approach.
Uh yes, like I said, one of the 2 alternatives you have is usign the old hardware to read the original media (and then you transfer it with whatever communications link you can manage). Point is, in order to do this, you need the old hardware, so this is no option whatsoever for replacing a machine that has given up, it is only an option when you do it beforehand.
> Yeah, but if you're going to build an I/O board and write custom emulation drivers, what's the cost compared to buying a new off-the-shelf system and tooling for the shop? Imagine the cost to hire contractors to tease apart the I/O specs on that old stuff just so they could then build a custom board and drivers to emulate the old software on a P4 or something. Compare that to reinvesting in a new system with tools. It's the new tooling which really costs. They've got an old system which works right now and they don't see the point in dumping a couple hundred grand or more to buy new stuff which does exactly what their old stuff still does perfectly well. Can't blame 'em. --M
Add to that that while a commercial solution might in itself notbe that extremely expensive, the changes to processes, and need for retraining, the resulting initial mistakes that will occur and so on cause quite a lot of extra costs.
> "Perfectly usable"... VAX... VMS... hahaha hhahaaahahhahaha. Good. Got that out of my system.
And while I hope it never happens to you, if you happen to get into hospital, there is quite some chance that your information will be registered on a.... VAX. that is right, an old, according to you obviously unusable VAX.
Next time you transfer some money, chances are quite good that your order will be processed by... again one of those unusable vaxen...
I suggest you delve a bit into the matter before laughing your ass off because this makes you look like someone who knows very little of what is being used.
> Given the current state of patent law, chances are that any universal Turing machine now owes Nintendo royalties.
I'd say.. prior art is undisputable in this case, so that would stand no chance whatsoever in court.
> Some programs create virtual CD-ROM drives when you give them an (.iso) image of a CD-ROM. You could say that the said program is emulating a CD-ROM drive.
Uh no, that is not the same at all.
An ISO image contains a filesystem that can be mounted using a loopback device or similar.
It in no way whatsoever tries to emulate a drive.
> Similarly, if you were emulating an old computer which has some kind of old disk drive, the drive itself would be emulated along with the rest of the computer. The data would be read from a file on the emulator's host's hard drive. Or maybe it could even read 3.5" disks that were formatted to hold no more data than the old disks. Either way, you woulnd't actually use one of the old disks.
Yes that works, but the problem is.. how do you get you old data in those files on your modern disk?
There is an aditional problem when you want to emulate devices like Commodore's 1541 and sfd 1001 drives, those are not like todays dumb floppy drives at all, they contain 1 or 2 (in case of the sfd 1001) cpus and you can run software on them. This feature was used quite extensively and you have to emulate that (which is done quite well by emulators like Vice for example)
Uh, there is a pdp-8 emulator aroudn that does this quite well.. the problem is more like.. where the hell do I insert that paper tape? :)
> Honestly, is it such a big deal these days to dump your media onto a network store and -then- switch over to the emulated system?
Lets say you have some ancient system with 8" floppies and no networking whatsoever. How are you going to dump those media on your network then?
(and no, not a troll, there are plenty old systems out there that did not network well or not at all)
Media conversion is the one biggest problem of emulation unless you can still access the original hardware and somehow connect it to a modern machine (as is done for exampel with Commodore's 1541 floppy drive) or alternatively, you get some modern reader to read ancient media.
> Native binaries, blessed by Sun, available on FreeBSD. Yes I know I should complain to Sun. Yes I know it isn't FreeBSD's fault.
What is more, this is not only a problem for FreeBSD, but for each and every OS that SUN doesn't feel like 'blessing'. Many Linux distributions suffer from related licensing problems and cannot distribvute JAVA binaries either.
> But would it kill the FreeBSD developers to try to work up a relationship with Sun?
It is why there is a jdk 1.3 binary for FreeBSD. The relationship between FreeBSD developers and SUN isn't really the issue, SUN's attitude, resources and unusable source code license are the issue.
It is a major annoyance for anyone who wants to do anythign with JAVA whatsoever and who cannot pay SUN for the resources (when SUN doesn't feel like it has a reason to do it itself ofcourse)
> Java support is great. It's been there for a while. The problem (traditionally) has been that fbsd won't run an app container or ejb container (I was told with a shrug, that it "had to do with threading"). Has that been fixed yet?
First of all, the issue you talk about is with the prebuilt jdk 1.3 as sanctioned by SUN.
The issue is that it supports green threads only, not native threads.
My experience with a jdk 1.4.2 built from the source is that it does support this, and that anything I tried (and that is not just some applets, but also tomcat + servlets and jboss + servlets) work perfectly well.
Could you point us at such a page about Linux? or should we conclude it is dying?
> You're absolutely right. However there's a difference between the developer claiming "usable for most tasks. However [...]" and a developer claiming a version is a "Production" version.
And in all my experiences (I know, anecdotal evidence, but still, obne that is confirmed by many others who tried) 'usable for most tasks' in the FreeBSD world is a lot more usable then 'production ready' in the Windows world, and even in the Linux world.
> I find it rather funny that most of the responses claim that I haven't looked at the ports tree. On the contrary, I have kept very close tabs on the advancement of Java under FreeBSD. Back when our app ran under 1.1.8, we happily deployed FreeBSD. I will be first in line to deploy it again when the 1.4 JDK is bumped up to production-ready.
Have you actually tried it?
I have been running the FreeBSD native port for a long time, both server and client side, and it simply works, period.
There is an issue, that issue is Sun's source code licensing. That is however not a technical issue, and if you can build it, it is very usable for a production environment also.
I'm currently playing with the 1.5 jdk.
> You don't get to call me moron, if you can't behave properly i have no wish to interact with you. I suggest you grow up.
I call you one if you behave like one. You are quite acting like the only thing that matters is what you think, while honestly you are clueless as to what you are talking about. Try to listen to people suggesting you might be mistaken instead of telling them off maybe.
> Newsflash: You don't get to decide what is correct. And "roaming profiles" are not desirable.
Let me tell you a little secret:
Microsoft specifies to quite a large extent how a Windows program should behave. The also made WIndows, so they determine what is considered correct behavior for a Windows program, not some clueless moron like you.
> When i switch between different windows installs or access program directories via network shares i'm screwed with such programs. No dice. I need programs which support the user not the megacorp
Maybe you should blame the design of windows for this and use another OS?
WHen you use windows, it really really really helps to at least observe the ideas that the people had who made it because they will determine how the thing works.
It is relevant how other windows programs work in this respect, you may have to maintain one computer with a few windows installs and have this problem, but virtually everyone else has to deal with multiple computers each with a single install and with user profiles stored in a central place.
If you'd make proper use of roaming profiles (provided your windows versions all support it) you would actually be able to share your configuration and settings between those multiple windows installs, but obviously you did not look enough into the matter to know this. Complainign is easier of course.
> It doesn't as it is. So that's easy enough.
I bet that is why peopel are using it.
> Boring on strawman argument there "I've never been mugged so nobody has been mugged". What you have or haven't seen isn't relevant.
Are you sayign here we should just ignore what you saw then?
> Actually no it isn't, since it doesn't support the Javascript 100% the user agent is irrelevant.
IE's document object model implementation is broken and needs a workaround which does not work in many other browsers (which do however properly implement the document object model)
It is IE that is broken according to the standards in this, not Firefox/Mozilla.
I suggest looking a bit more, usign your brains a bit more, and complaining a bit less.
1: You download a file, not a title. IE behavior with regards to that annoys the hell out of me, and is technically incorrect also.
2: Valid comment, do not know how that is in the current version.
> Its still not compatible with MSIE javascript.
Uh...
You mean to say:
IE is still not fully compatible with the DOM and DOM2 specs (getElementsByTagName('*') to give an example where IE messes up in each and every version).
IE provides some alternatives, and quite a few coders think that those are the only way to do thingws (document.all to name one example)
I'm sorry to say, but it is IE being broken here, and not with regards to Javascript so much as the document object model.
And that saying just means to not trust the police or other law enforcement.