@cdimauro

Quote:

cdimauro wrote: Frankly speaking, if this is the case I don't see any advantage of this solution over the USB-ones already available. BTW, USB can generate interrupt to the CPU, if I remember correctly.

Not really. USB is based on a relatively simple polling system and conceptually the device can only indicate an exception by providing a certain packet when polled. In the basic USB system the USB host driver then can generate an "interrupt" to the device driver.

The advantage with this is cost of implementation, the disadvantage is increased communication latency. But USB wasn't designed to replace things where very low latency is a requirement and for most other things 1ms latency (ignoring device drivers) is acceptable

(And I should probably add that the polling mentioned above is done in hardware and that DMA and other techniques are used to reduce CPU load. I've seen a lot of Amiga people that thinks USB is software polled.)

@megol: thanks for the information. 1ms can be good for many tasks, but USB is too limited for more strict problematics.

@cdimauro

Quote:

cdimauro wrote: @Dandy ... This "new" was already discussed here. Please, take a deep look at the discussion, because it deserves.

I'm just following your advice to take a deep look at the discussion.

Quote:

cdimauro wrote: Anyway, a piece of the discussion was missing. I report again everything about that point: "However implementing things like 64-bit and SMP for AOS means losing its backward compatibility with existing applications (both PowerPC and 68K). That's why you'll not see a 64-bit version of it, and only a multicore (not SMP) support will be added."

While "taking a look", I followed a link in this thread and found this:

Quote:

Hans-Jörg Frieden wrote: ... Downsides of the ExtMem system ... However, as I already outlined in the beginning, there is a lot of work involved to make AmigaOS 64 bit compatible, and with the method of ExtMem objects, breaking the barrier is possible now as opposed to years down the road. ... Hans-Jörg Frieden, May 22nd, 2014

As H.J. Frieden uses the indicative "there is a lot of work involved" (and not the subjunctive "there would be..."), I understand it this way that they are actually working on making AmigaOS 64 bit compatible.

Furthermore, as he says "breaking the barrier is possible now as opposed to years down the road.", I tink it already works.

Quote:

cdimauro wrote: So, if they decided to implement SMP (which doesn't seems to be a real SMP: read the above discussion), it means that they are sacrificing the backward compatibility (in some measure: it depends by the kind of multicore implementation, and by the single application), as I already reported several times.

The opinion of the participants to the discussion is one thing, but an official statement of one of the core developers of AmigaOS 4.x is another.
I tend to believe what was stated in the official statement of one of the core developers, which I already cited in my posting #1191.

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@Dandy

HJF was specifically talking about "breaking the 2GB memory barrier" without going 64-bit.

_________________
Troll - n., A disenfranchised former potential customer who remains interested enough to stay informed and express critical opinions.
opp., the vast majority who voted silently with their feet.

@Dandy

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: Anyway, a piece of the discussion was missing. I report again everything about that point: "However implementing things like 64-bit and SMP for AOS means losing its backward compatibility with existing applications (both PowerPC and 68K). That's why you'll not see a 64-bit version of it, and only a multicore (not SMP) support will be added." While "taking a look", I followed a link in this thread and found this: Quote: Hans-Jörg Frieden wrote: ... Downsides of the ExtMem system ... However, as I already outlined in the beginning, there is a lot of work involved to make AmigaOS 64 bit compatible, and with the method of ExtMem objects, breaking the barrier is possible now as opposed to years down the road. ... Hans-Jörg Frieden, May 22nd, 2014 As H.J. Frieden uses the indicative "there is a lot of work involved" (and not the subjunctive "there would be..."), I understand it this way that they are actually working on making AmigaOS 64 bit compatible. Furthermore, as he says "breaking the barrier is possible now as opposed to years down the road.", I tink it already works.

Please, read the full text:

"Obviously, the method is a compromise. A “real” 64 bit system would be better, and much more transparent to use. However, as I already outlined in the beginning, there is a lot of work involved to make AmigaOS 64 bit compatible, and with the method of ExtMem objects, breaking the barrier is possible now as opposed to years down the road."

As Boot_WB correctly reported, this talks only about how to use memory >2GB, and this does NOT require any 64-bit support, since PowerPCs already allow it.
Quote:

Quote: cdimauro wrote: So, if they decided to implement SMP (which doesn't seems to be a real SMP: read the above discussion), it means that they are sacrificing the backward compatibility (in some measure: it depends by the kind of multicore implementation, and by the single application), as I already reported several times. The opinion of the participants to the discussion is one thing, but an official statement of one of the core developers of AmigaOS 4.x is another. I tend to believe what was stated in the official statement of one of the core developers, which I already cited in my posting #1191.

I prefer to judge the facts myself, instead of taking as gold what OS4 developers said.

Remember that they said that SMP would be added in less than 2 years, and 4 years are passed away (and still waiting). They then said that SMP will be added, but even tried to change the definition of SMP to fit the multicore approach that they are working on.

And see above: they talked about "64-bit awareness" to access more memory, whereas the o.s. continues to be strictly 32-bit and the so called ExtMem objects just use a standard feature of PowerPCs to map >4G memory in a 32-bit address space.

So, I don't believe: I prefer to see and evaluate. As usual.

@Boot_WB

Quote:

Boot_WB wrote: @Dandy HJF was specifically talking about "breaking the 2GB memory barrier" without going 64-bit.

Hmmm - are you sure?
Here's what I just read after following the link on Amiga-News.de:

Quote:

Hyperion Entertainment wrote: AmigaOS 4.1 Final Edition SDK available for download Brussels, August 30, 2015 Hyperion Entertainment CVBA is pleased to release the Software Development Kit (SDK) for the largely successful AmigaOS 4.1 Final Edition. This SDK enables third party developers to access all the enhancements and new features added in AmigaOS 4.1 Final Edition including: • New components such as btree.library, diffview.gadget, diskio.library and z.library. • Unified graphics.library API with built-in RTG support as the original Amiga designers intended. • Access to the new composited video feature. • Extended memory which goes beyond the 4 GB memory barrier. • New Unicode functions for handling UCS-4 and UTF-8 sequences. • Next generation menu system in intuition.library via menuclass. • Improved dos.library API. • Extended and improved console.device API. Additions and updates to the SDK itself include: • Updated standard tools like autodoc, CatComp and grep. • New FSTest and FSVPTool file system development tools. • Updated clib2 alternative C standard library. • MUI 4 SDK. • Massively updated and improved perl 5 install. • AutoDocViewer included. • Updated MiniGL SDK for 3D applications.

Doesn't this mean that they passed the limit of what's possible with 32 Bit?
And I understand "passing the limit of what's possible with 32 Bit" as going 64 Bit.
This would most closely correspond to what was announced...

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@Dandy: please, read the following links:
http://blog.hyperion-entertainment.biz/?p=863 (64 bit address space awareness, which then become ExtMem)
https://en.wikipedia.org/wiki/Physical_Address_Extension (only to understand the concept)
http://stackoverflow.com/questions/11721279/virtual-address-for-processes-having-more-memory-than-4gb (Benoit's answer regarding PowerPC)
ftp://ftp.acer.fr/gpl/AS1800/linux-2.4.27/include/asm-ppc/mmu.h (include file for handling MMU & addresses on Linux)

@cdimauro

Quote:

cdimauro wrote: @Dandy ... Please, read the full text: "Obviously, the method is a compromise. A “real” 64 bit system would be better, and much more transparent to use. However, as I already outlined in the beginning, there is a lot of work involved to make AmigaOS 64 bit compatible, and with the method of ExtMem objects, breaking the barrier is possible now as opposed to years down the road." As Boot_WB correctly reported, this talks only about how to use memory >2GB, and this does NOT require any 64-bit support, since PowerPCs already allow it.

According to the latest news, this very well talkes about going beyond the 4 gB barrier (see my reply to Boot_WB), what in turn equals to going 64 Bit for me.

Quote:

cdimauro wrote: So, if they decided to implement SMP (which doesn't seems to be a real SMP: read the above discussion), it means that they are sacrificing the backward compatibility (in some measure: it depends by the kind of multicore implementation, and by the single application), as I already reported several times.

Hmmm - as far as I understood the expert's comments it could happen that some apps don't work anymore, but most will. But maybe this is a language-barrier-problem...

Quote:

cdimauro wrote: I prefer to judge the facts myself, instead of taking as gold what OS4 developers said.

So do I.
Just that I concede to the core developers that they know best what they want to do, what can be done, how it could be done and what cannot be done.

I take all the comments of all the non-AOS-developers around here as what they are: speculations.

And speculations can be close to reality or far away from reality - time will show.

Quote:

cdimauro wrote: Remember that they said that SMP would be added in less than 2 years, and 4 years are passed away (and still waiting).

I also remember that developing OS 4.0 took a lot longer than anticipated.
Remember the developers "When its done!" stock response?


Quote:

cdimauro wrote: They then said that SMP will be added, but even tried to change the definition of SMP to fit the multicore approach that they are working on.

I'm not so deep in the tech details to be able to judge this.
And, t.b.h., I'm not willing to dive so deep into the tech details.
All I'm interested in as a potential customer and user is to get access to modern and powerful Amiga hardware, that AmigaOS can take full - no, better: maximum - advantage of.
"Maximum" because it might perhaps turn out that AmigaOS cannot be tweaked enough to take full advantage of the hardware, but it can be tweaked to take the maximum possible advantage of it, to make the best of it, so to say.

Quote:

cdimauro wrote: And see above: they talked about "64-bit awareness" to access more memory, whereas the o.s. continues to be strictly 32-bit and the so called ExtMem objects just use a standard feature of PowerPCs to map >4G memory in a 32-bit address space.

As long as it allows me to use e.g. 16 gB RAM or even more I'm fine with that...

Quote:

cdimauro wrote: So, I don't believe: I prefer to see and evaluate. As usual.

O.K!
After all this is not religion, but IT stuff...

Last edited by Dandy on 01-Sep-2015 at 12:01 PM.

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@cdimauro

Quote:

cdimauro wrote: @Dandy: please, read the following links: http://blog.hyperion-entertainment.biz/?p=863 (64 bit address space awareness, which then become ExtMem) https://en.wikipedia.org/wiki/Physical_Address_Extension (only to understand the concept) http://stackoverflow.com/questions/11721279/virtual-address-for-processes-having-more-memory-than-4gb (Benoit's answer regarding PowerPC) ftp://ftp.acer.fr/gpl/AS1800/linux-2.4.27/include/asm-ppc/mmu.h (include file for handling MMU & addresses on Linux)

Thanks for all the links, mate! That will keep me busy for a few days...

Last edited by Dandy on 01-Sep-2015 at 12:17 PM.

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@Dandy

Quote:

Dandy wrote: @Boot_WB Quote: Boot_WB wrote: @Dandy HJF was specifically talking about "breaking the 2GB memory barrier" without going 64-bit. Hmmm - are you sure? Here's what I just read after following the link on Amiga-News.de: Quote: Hyperion Entertainment wrote: AmigaOS 4.1 Final Edition SDK available for download Brussels, August 30, 2015 Hyperion Entertainment CVBA is pleased to release the Software Development Kit (SDK) for the largely successful AmigaOS 4.1 Final Edition. This SDK enables third party developers to access all the enhancements and new features added in AmigaOS 4.1 Final Edition including: • New components such as btree.library, diffview.gadget, diskio.library and z.library. • Unified graphics.library API with built-in RTG support as the original Amiga designers intended. • Access to the new composited video feature. • Extended memory which goes beyond the 4 GB memory barrier. • New Unicode functions for handling UCS-4 and UTF-8 sequences. • Next generation menu system in intuition.library via menuclass. • Improved dos.library API. • Extended and improved console.device API. Additions and updates to the SDK itself include: • Updated standard tools like autodoc, CatComp and grep. • New FSTest and FSVPTool file system development tools. • Updated clib2 alternative C standard library. • MUI 4 SDK. • Massively updated and improved perl 5 install. • AutoDocViewer included. • Updated MiniGL SDK for 3D applications. Doesn't this mean that they passed the limit of what's possible with 32 Bit? And I understand "passing the limit of what's possible with 32 Bit" as going 64 Bit. This would most closely correspond to what was announced...

Still using a 32-bit address space (4GB), half of which is reserved, herefore memory cannot be mapped into this address space: hence the 2GB usable memory barrier (which is essentially 1.xGB since i/o etc is also mapped into this space).

The ability to make some use of more than this, as I understand it, relies on reserving even more of this limited space as a "window" into which actually memory can be swapped into in chunks. A much slower process than having addressable ram available, and afaik the extra ram isn't transparently available to applications and can only be used if coded for using extmem objects.

Could be wrong though, haven't read much about it beyond the concept description.

_________________
Troll - n., A disenfranchised former potential customer who remains interested enough to stay informed and express critical opinions.
opp., the vast majority who voted silently with their feet.

It's funny how people laughed at DOS/x86 in the nineties with the Extended memory hack that was needed to access memory beyond 640kb. And they were right.

And today the very same people try to bypass current OS+CPU limitation, just like DOS did...

Isn't it high time to move on and forget about hacks ?

Last edited by Leo on 01-Sep-2015 at 02:27 PM.

_________________
http://www.warpdesign.fr/

@Dandy

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: @Dandy ... Please, read the full text: "Obviously, the method is a compromise. A “real” 64 bit system would be better, and much more transparent to use. However, as I already outlined in the beginning, there is a lot of work involved to make AmigaOS 64 bit compatible, and with the method of ExtMem objects, breaking the barrier is possible now as opposed to years down the road." As Boot_WB correctly reported, this talks only about how to use memory >2GB, and this does NOT require any 64-bit support, since PowerPCs already allow it. According to the latest news, this very well talkes about going beyond the 4 gB barrier (see my reply to Boot_WB), what in turn equals to going 64 Bit for me.

Please, read Boot_WB's reply: there's no 64-bit support at all. Just a PowerPC feature, like what x86 had from very long time, without using x64.
Quote:

Quote: cdimauro wrote: So, if they decided to implement SMP (which doesn't seems to be a real SMP: read the above discussion), it means that they are sacrificing the backward compatibility (in some measure: it depends by the kind of multicore implementation, and by the single application), as I already reported several times. Hmmm - as far as I understood the expert's comments it could happen that some apps don't work anymore, but most will.

Can be, but we aren't sure.
Quote:

But maybe this is a language-barrier-problem...

It's a problem of the o.s. here.
Quote:

Quote: cdimauro wrote: I prefer to judge the facts myself, instead of taking as gold what OS4 developers said. So do I. Just that I concede to the core developers that they know best what they want to do, what can be done, how it could be done and what cannot be done. I take all the comments of all the non-AOS-developers around here as what they are: speculations. And speculations can be close to reality or far away from reality - time will show.

Sorry, but I concede nothing only for the so called "authority principle". Many people here have a good IT knowledge base, which allows them to evaluate the writings, from whatever source they come.
Quote:

Quote: cdimauro wrote: They then said that SMP will be added, but even tried to change the definition of SMP to fit the multicore approach that they are working on. I'm not so deep in the tech details to be able to judge this. And, t.b.h., I'm not willing to dive so deep into the tech details. All I'm interested in as a potential customer and user is to get access to modern and powerful Amiga hardware,

The post-Amiga PowerPC hardware isn't modern neither powerful, and there's no future for it, ad it was discussed recently in another thread.
Quote:

that AmigaOS can take full - no, better: maximum - advantage of. "Maximum" because it might perhaps turn out that AmigaOS cannot be tweaked enough to take full advantage of the hardware, but it can be tweaked to take the maximum possible advantage of it, to make the best of it, so to say.

Take a look at the graphics cards: they evolve so much that no post-Amiga platform is able to squeeze the most from them.

Another example is USB3...
Quote:

Quote: cdimauro wrote: And see above: they talked about "64-bit awareness" to access more memory, whereas the o.s. continues to be strictly 32-bit and the so called ExtMem objects just use a standard feature of PowerPCs to map >4G memory in a 32-bit address space. As long as it allows me to use e.g. 16 gB RAM or even more I'm fine with that...

But that's another thing, albeit we are talking about the the infamous bank-switching tecnique.
Quote:

Quote: cdimauro wrote: So, I don't believe: I prefer to see and evaluate. As usual. O.K! After all this is not religion, but IT stuff...

Not in the Amiga or Apple domain.

@Leo

Quote:

Leo wrote: It's funny how people laughed at DOS/x86 in the nineties with the Extended memory hack that was needed to access memory beyond 640kb. And they were right.

Absolutely. I was one of them, which laughed a lot about such ancient "feature".
Quote:

And today the very same people try to bypass current OS+CPU limitation, just like DOS did...

Coherency...
Quote:

Isn't it high time to move on and forget about hacks ?

You have to tell it to the right persons.

NUMA hardware for AmigaOS?
Non-uniform memory access (NUMA)

Where and for what is more computing power needed? PC/notebooks are already good enough for most tasks/jobs - they are so good, that somehow big and kinda not so efficient operating systems (OS) can exist, can even be the most used OS.

Well, there are internet server, real big data bases (think of NSA, google, facebook, twitter and so on), computer-aided design (CAD), CGI animation (for games, video and film), scientific/academic supercomputing and so on. One can't have enough computing power, especially for the ultimate game changer, the technological singularity Artificial intelligence (AI). Yeah, don't underestimate AI, just look at this (sorry, only in German): die Zukunft der Menschheit hängt davon ab.

What has Amiga to do with supercomputing and AI? Well, right now not much but the question still is: How to make Amiga OS a leading operating system?

As above said, the AmigaOne X1000 has already enough power for most usual tasks ... but what if one wants more? Well that's easy: just develop/build a coprocessor extension card. There exist already some pretty impressive examples, think of quite impressive modern video/graphics cards (with even more than 250 W energy consumption but often under 1000 Euro), for instance (sorry, only in German):

AMD Radeon R9 Fury X: Mit Wasserkühlung und 8,6 TFlops
AMD Radeon R9 Fury X dank HBM-Speicher mit 512 GByte/s
AMD: 4K-Grafikkarten mit Stapelspeicher noch in diesem Quartal
HBM-Spielergrafikkarte: Spezifikationen der AMD Radeon R9 Fury enthüllt

That is only a little example of what is already possible but the future is AI and for that one needs multi-purpose extension cards. These could have 4 (or more) SSD, with each up to 1 TB (and more in the future) with a file system and the ability to search and manage data independent with their own CPU/SoC. There could be 4 or 8 CPU/SoC each with 2 or 4 GB DDR SDRAM or more and that's where NUMA steps in: the memory could be high bandwidth sharable. Just think of what you can stick together with an limit of TDP 250 W and less than a price of 10.000 Euro (that may sound much but think of billion Euros out there, think of companies, universities, the military complex and of cource millions of millionaires).

Remember: reliability, efficiency, security and data safety are more important than computing power. an undetected data error must be nearly impossible ... and that means some extra bits for error detection and not to much heat (and that means that there must be an configurable heat limit - some would prefer data safety before speed). Obviously there could be a tower/rack for multiple extension cards.

Do you still remember the idea of an 48 bit CPU/SoC? Well, that could be not the worst idea. Also very important: a clear and efficient design (no speculative execution, no fancy rollbacks) and don't forget KISS - the software could be optimized for the system.

Yeah, that's pretty much - too much for current Amiga but a simple multi CPU/SoC extension card with existing hardware (PowerPC, DDR SDRAM, SSD, ...) could be possible and could find customers elsewhere worldwide. For the long run one needs the ideal system and that has still to be designed/build and at the beginning there's always the idea, a simple thought - well, maybe, here it already is.

The human brain consumes only 20 watts and has perhaps only 10^13 (10 tera) FLOPS and these are less precise than 4 byte single precision ... and today's advanced video cards nearly have those 10 TFLOPS. Most people couldn't even learn 1 kB random chars quickly (not in hours) but an computer could easily store and compute gigabytes in seconds. A computer can work around the clock and don't forget anything.

Yeah, artificial intelligence on a PC is not in sight soon but how about an knowledge expert system? The probably most important aspect of AI is decision-making and contradiction-detection and that's mainly data (knowledge base, storage, computing) an logic. AI is mostly a system of data and logic - the aim/goal is, to build such a system and today's hardware is already good enough.

The task is, to build an efficient system and a 250 W extension card could very well be the starting point - think of millions of users who build together an open source System/AI (not necessarily connected - they work together to improve a single system) ... and sometimes a 10 kW (100 kW should be more than enough) computer/server could be an AI at home, at office, and so on.

The coprocessor extension card is multi-purpose it could be used for gaming also - this could be pretty interesting and a new way: not just optical complex (4K) games (often with annoying fog and blurred in the background or am I wrong?) but also very interesting games with huge VR worlds, perhaps computer generated, self changing and so on. A moving scene could be low resolution and when you stand still and just watch, the scene could be rendered in full 4K detail - that could be pretty awesome ... and efficient also. A played scene could be later (perhaps over night) rendered to a full detail video and there could be competitions (for the best game play video). (all imho)

@KingKong
Cloud....
Computers will become Access Points to a collective System.
The power of the accessing device is irrelevant.. it become just a remote. (a phone for instance)

So the "Technology" can become clumsy again. A big Network of supercomputers and all connected devices serving al requests.

To be honest I don't see the Need for multiprocessing on a consumer device anymore as Long it has a Internet Connection..

This is the Chance to bring AmigaOS on par or even a bit further than Mainstream oses.

This is at least what i plan for next Broadway release. Let the big guys do your work.... stream apps to the workbench. Basically like AEROS but the apps are not running on you local machine(via Linux) but on a Server.

Last edited by phoenixkonsole on 14-Sep-2015 at 11:01 AM.
Last edited by phoenixkonsole on 14-Sep-2015 at 11:01 AM.

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

@phoenixkonsole

Given that my internet connection is of the "mobile" variety, and my ISP is capping my datause at 12GB per month, I am about as far away from worshipping the idea of cloud computing as it would be possible to be.

12GB a month is bad enough between me and the internet, but between me and my harddrive/CPU/GPU etc? How the heck would that work, really?

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@KingKong

Quote:

Where and for what is more computing power needed?

For any task you want to do quickly, like scale / rotate images (they get bigger every day), render 3D, game engines, etc etc.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@olegil

Quote:

12GB a month is bad enough between me and the internet, but between me and my harddrive/CPU/GPU etc? How the heck would that work, really?

It would work very well ................... for your service provider. The cloud (whilst having useful aspects) is all about marketing and selling stuff.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@olegil
Imagine your files are stored in a online storage (there is no traffic)
The app and all data calculated is also stored in the cloud (there is no traffic)
The only traffic is caused by Streaming Input and Output from your mouse/Keyboard and Audio/Video.

This only if you stream a whole deskop.

Cloud-processing again is different. You can for instance build a local running gui or App and let only do calculations by the cloud.

Again.. the files are stored on your cloud storage.

Also your files (if changed and if you Need local copies) will cause only traffic once if changed.

So you can get a lot computational power with 12GB a month. (everthing running on the cloud cause no traffic... you could download stuff from web to the cloud and run it from there without downloading it locally)

Last edited by phoenixkonsole on 14-Sep-2015 at 12:18 PM.
Last edited by phoenixkonsole on 14-Sep-2015 at 12:17 PM.
Last edited by phoenixkonsole on 14-Sep-2015 at 12:16 PM.
Last edited by phoenixkonsole on 14-Sep-2015 at 12:15 PM.

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

@phoenixkonsole

Which protocol exactly is it you're thinking of streaming my GUI across that will take up less than 12GB a month? 12GB/month = 14.4kB/s for 8 hours per day. A few minutes of real time video.

Unless I'm also somehow in the cloud so I don't need to manipulate (nor view) my data?

Don't get me wrong, I've used distcc and I'm using SVN/GIT etc. But at some point I need to actually edit the text files and route the wires of my PCBs (finishing a PCB as we speak, only need to calculate impedances for 2 10Gbps pairs and create the gerbers).

Back when I lived in a place with fiber I used Opera running on my home server while sitting at work (ssh with X forwarding). So it's not that I don't understand the concept of working remotely. I just don't see how it's useful until I get gigabit between home and office.

Last edited by olegil on 14-Sep-2015 at 01:18 PM.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.