element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      • Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Raspberry Pi
  • Products
  • More
Raspberry Pi
Raspberry Pi Forum Initial Thoughts and Experiences
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Raspberry Pi to participate - click to join for free!
Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 22 replies
  • Subscribers 678 subscribers
  • Views 2940 views
  • Users 0 members are here
  • raspberry_pi
Related

Initial Thoughts and Experiences

Former Member
Former Member over 13 years ago

Three days ago my Pi arrived via UPS and I've been playing around with it a bit. I thought I'd write my comments about it for the benefit of those interested and so that I can receive some tips/ideas.

 

First and foremost, I apologize about the lack of pictures, my digital camera broke a few months ago and I never replaced it since I don't take a lot of pictures, I can put some from my cellphone later on if people are curious but there are a lot of pictures out there already.

 

I ordered my Pi on March 12th from Newark for delivery to New Mexico in the U.S. (I live on NMSU's main campus) and it arrived on the 10th of July at approximately noon (I took the day off from my job as a research assistant, informing my professor that I was expecting a new "tinker toy" to come in). This was after three weeks of my shipping date changing at the last second to exactly one week later (it was always listed to be shipped on a Thursday, and come that Thursday morning, would be pushed to the Thursday exactly one week later).

 

When it finally did ship (element14 listed it as "Complete" and gave me a tracking number) I noticed a charge on my credit card of $50.75 from element14 when my order listed my price as $44.76. I contacted customer service and things got a bit weirder, according to the customer service rep. I was only supposed to be charged $42.05 (which is what my invoice says, but my order still listed the previously quoted price). Eventually they gave me the contact info for their credit department, who I contacted by email and still have never gotten a reply (but the charge was fixed to the lower price, so I never bothered investigating it any further).

 

My Pi did not arrive in a box with "Raspberry Pi" written on it like many others seem to have gotten. Mine came in an envelope with bubble wrap on the inside from element14 and upon opening it there was a tiny white box no larger than the Pi itself, with the Pi being inside of that.

 

Fortunately my power supply arrived at the same time (same UPS guy), I ordered a cheap Motorola power supply that was listed as being compatible (on the elinux wiki I believe) from Amazon.com:

http://www.amazon.com/gp/product/B004EYSKM8/ref=oh_details_o02_s00_i00

 

Unfortunately, my desktop's keyboard uses an old PS/2 connector (been so long since I hooked it up I had forgotten and just assumed it was USB) which is what I had planned on using with my Pi, so then I drove around town looking either for a cheap USB keyboard or PS/2 to USB adapter (my dedicated USB keyboard for the Pi arrived two days later), I ended up buying a cheap USB "Onn" brand keyboard from Wal-Mart for $9 because all the PS/2 to USB adapters I could find in-store (not online) were $21+ and the cheaper keyboards were all wireless (I prefer wired, batteries always seem to die at the most inconvenient of times while I never need to change the wire on something wired unless for some reason I happened to cut the wire).

 

So great, I was up and running, mostly. I still needed to write an image to an SD card run that. The 4Gb SD card I had ordered specifically for the Pi still hasn't arrived, but luckly I had an extra 4Gb microSDHC card from an old phone as well as a microSD to SD adapter "sleeve" (the microSDHC card slides into it and then can go into SD slots) which I put the Arch Linux Arm image on (I will be testing the other distros later, just more familiar with Arch at the current moment).

 

My monitor connects to the Pi via HDMI and runs at 1680x1050, which the Pi almost did on its own. For some strange reason Overscan was setup and I was getting roughly 15 pixels on all sides as a buffer, I have no idea why this is set as I've never run into this on anything else (I've used many distros of linux, and during the school semester work for my university's physic's department as an IT Assistant, mostly dealing with setting up computers for the graduate students and helping them with any problems they run into since linux is almost exclusively used for research). This was simple enough to turn off, just went into the /boot directly and edited the config.txt to disable overscan and rebooted, nice and normal again.''

 

I'm enjoy running a minimal linux install personally, mostly because I deal with older hardware on a regular basis (and I've never been lucky enough to afford some ultra powerful computer, usually I search around every 5 years for a new machine with a budget of about $500 total for a desktop and $400 total for a laptop which is good enough for day to day use but not good enough to run any recent games). Currently on my laptop I run DWM and thought it would be pretty good on the Pi, using the standard 192/64 CPU/GPU memory split and installing DWM left me with very little memory running while idling (when idle I'm not sure how much I was left with, but idle with Conky running and being piped to dmenu every 2 seconds left me with only about 1Mb of memory, so my assumption is to either not run Conky or to update it much less frequently). Opening up a terminal would have about a 3-4 second lag from pressing the key combination of Alt+Shift+Enter (DWM key setup to open uxterm, I changed rxvt with unicode support). Didn't run as fast as I had liked, opening up Surf to browse the web would take about just as long (3-4 second lag to press Alt+P in order to enter command into dmenu and then 3-4 second lag for surf to open, about 2 seconds to load google.com from the university internet connection). That isn't all that bad, but not as responsive as I would've expected (I know, everyone talks about how weak the machine is, but I used a Pentium 2 machine with 128Mb ram up until 2003 (running Windows 9x, hadn't discovered linux yet) and then a Pentium 3 750 Mhz machine with 256Mb of ram with Windows XP and Linux up until 2007 (discovered linux in 2005) with better performance on each then than with the Pi now, so it can't be the hardware like how everyone enjoys to blame, it is most likely a side of effect of software needing to be compatible with newer standards). Heck, my android phone runs at 700Mhz (Huawei Ascend 2).

 

Anyway, after that I installed DVTM (basically a console version of DWM) and dropped X entirely, which runs great after you delete /etc/profile.d/locale.sh (this is recommended in an old Arch Linux announcement, always end up forgetting all the steps to take when updating a fresh Arch install as it involves sifting through the annoucements from the past and checking to see if they apply or not anymore) (otherwise DVTM displays a bunch of gibberish where it would typically draw lines and write info about each "window"). I even got retroarch (a multi-platform, multi-console emulator front end based off the libretro emulator cores [only managed to get SNES emulation running using the pocketsnes core supplied by ToadKing's github]). Took a while to get running, an embarrassingly long time actually. I was up all night (forgot to sleep) messing with it, primarily because SDL didn't want to run (kept trying to make a surface along the lines of 159000x159000, so I spent a considerably amount of time sifting through the retroarch source trying to figure out what was causing this since nobody on their forums seemed to have encountered the same problem and I wanted to be sure I did an exhausted troubleshoot before bothering others on the forum with my problem). Unfortunately I'm not that familiar with SDL and am honestly not much of a programmer (typically write short codes to collect data, calculate something in either Fortran or MatLab, or simulate a system using Fortran, not much C experience), and eventually gave up. After getting some much needed sleep I tried again with a fresh download of retroarch from ToadKing's github and compiled it (had to use the --disable-sinc feature when running ./configure otherwise it wouldn't compile, something about alinged_alloc being statically defined and then non-statically defined later in the audio/sinc.c file, nobody else seemed to have this problem and I only did a quick sift of the file to try to see if my limited programming skills could resolve this issue, which I couldn't). Also needed to link a folder in /opt/vc (cannot remember which, it is listed in their forum) that rpi.c needs while compiling otherwise it will not detect that you are using the program on a Pi (runs on PC, Mac, XBOX 360, PS3, etc..). After all that is said an done, and making a retroarch.cfg to my liking (changed the input settings) I was able to get it to work, but it breaks whenever I turn on the Audio Sync setting (which is recommended in the default config file). Sound is hit or miss, since the Pi's sound driver is still in an early stage (I believe either pre-alpha or alpha, can't recall) and works for the first 2-3 seconds of running Super Mario Bros. (the game freezes when the first black box message appears on the first level). I've been able to run Ogre Battle with no issues aside from cruddy sound, as well as Super Mario RPG (which runs surprisingly well considering Super Mario Bros. freezes and RPG runs the system much harder) with relatively good sound. EarthBound runs like a champ except when characters enter or leave your party (lags for a couple seconds before the message pops up, but does not freeze) and sound works fine indoors but becomes pops and hisses in the outside world and when going through doors. Chrono Trigger runs fine with no lag but sound does not work at all for me.

 

I'm mostly testing what the Pi is able to do based off of what it currently available, not off of what I could program it to do. I also installed Yaourt, which is much easier as you just use pacman -S yaourt instead of the round-about way you need to on regular Arch Linux and most packages install fine if you edit the PKGBUILD, particularly the "arch" line and add in "arm" it'll work about 7/10 times. Can compile most of the programs I tried to so long as I was in the console, with only one "window" in dvtm open and the 224/32 CPU/GPU memory split (no swap!).  I couldn't manage to get cups to work for my printer, I have a Brother MFC-9010CN color laser printer on my network that used to be a pain to set up (roughly 2 years ago) but is now a piece of cake as support for it has improved greatly. Unfortunately adding it using lpadmin -p [name] -E -v lpd://printer-ip-address/binary_p1 -m [ppd file for printer] would set up the printer, but it would only print blank pages with some faint multi-colored lines on it (using lpr [file] after the printer was made the default using lpoptions -d [name]). If I used the option to print the raw file (can't remember the lpr option at the moment) it would print the first line of what was in the file, but upon going to the next line would continue (didn't recognize the return, perhaps if the file was formatted with a "\n" at the end of each line, but did not test, ended up giving up since I don't need it to print, just wanted to see if I could make it print). The cups web interface could not install the printer, it would always fail at finding the "drivers" giving a failed message and a success message at the same time and not adding it to the list of printers.

 

Today I was planning on trying out the Raspbian image on a different SD card and playing with that, to see what I could get it to do. That is my overall experiences so far. I hope this either helps someone, or sparks an interest in someone (that way I'm not just writing it to "hear myself talk", so to speak) and I'd be happy to answer any questions or try any suggestions anyone offers (or test any ideas for those who have yet to get their Pi). Also, I have been able to ssh from my laptop to my Pi, providing I was on the exact same network (I sort of have a 2 network setup at home, my main router is downstairs as the is where the "live" phone line in student housing is for the dsl modem to connect to, but my office is upstairs so I have an Amped Wireless Range Extender SR150 (or 1500, cannot remember how many 0's in the name) that my desktop is plugged into (and the Pi is plugged into) which makes a "second" network that runs off the "first" network wirelessly (better than running Cat5 cables upstairs along the walls).

 

I'll try to document more of my experiences with the Pi if anybody is interested, and as I said I'm willing to take requests.

  • Sign in to reply
  • Cancel
  • morgaine
    morgaine over 13 years ago

    Good write-up, Alexander.

     

    Nice to see you get Arch up.  I haven't tried it yet, but I am intending to do so once Debian is fully operational on my Pi.

     

    I too have some old Linux machines on my network, including a 400MHz AMD-K6 with only 64MB RAM and a 750MHz P3, and just as you report, they both seem a lot more responsive than the Pi.  I haven't examined exactly what makes them faster yet, but I expect that in part it's the hard disk drives.

     

    Have fun. image

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to morgaine

    some known reasons for slowness are:

       1) SD card slowness;  some firmware improvements have been

    made recently, but probably best to put root filesystem on a usb

    stick or usb hard drive;

       2) L2 cache is connected to GPU, not CPU, so doesn't do much

    at all for CPU;

       3) GPU isn't used for X Window acceleration, or for music;

       4) hardware floating-point isn't used, except for Raspbian OS

    and Gentoo;

       5) USB causes 8000 interrupts/second even when idle, using up

    about 20% of the CPU;

       6)  ethernet goes through USB hub, which is polled.

       7)  lack of RAM can cause swapping, or can reduce I/O buffers;

       8)  libc has a slow version of memcopy (being fixed);

       9) USB is only 2.0, not 3.0; ethernet is 10/100, not 1000;

    10) ARM11 is pretty primitive, introduced in 2002;

    11)  Debian is built for ARM v4, not v6;

    12) unaligned memory accesses may be slow.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    coder27,

     

    Some of your options don't make sense to me:

    There is no swap, so swap usage slowing things down "shouldn't" be the case (doesn't make much sense to call swap when it doesn't exist and swapon hasn't been issued).

    USB 2.0 still has an awfully high data rate (and quite frankly, I've never used 3.0 so I don't think I would notice the performance loss from using 2.0), if it were using 1.1 I would understand the usb slowing maybe... my usb mouse or keyboard image (never mentioned, nor had anything else hooked up to usb).

    I've had hardware older than 2002 run better with lower specs than the Pi has, the year it was developed doesn't mean a whole lot to me, just because it is an old technology, doesn't automatically explain it's performance image.

    Not currently using Debian, so not currently relevantimage.

     

    8000 polls/second is still nothing compared to over 700 Million cycles/second, that is several orders of magnitude larger. So even if it involved multiple cycles per poll, I have a hard time believe this 20% of cpu power mentioned. The ethernet is 10/100 and not 1000, how exactly would this effect the rate a terminal emulator opens, or how quickly a browser is openedimage. That should only effect the page loading speed of the website I direct it to (also, lynx, w3m and elinks all work excellent, so I don't even think I really affects the page loading speed to a noticeable degree, it's not like I'm trying to load a huge flash file or anything along those lines).

     

    Memory access I don't know much about. Libc, I don't know much about. GPU not going to X I was not aware of, and I've never known of a GPU going to sound (Graphics Processing Unit, of course I could be wrong there, always used onboard sound for computers and I've never met someone who desperately needed an awesome sound system for anything important like their work or their research). SD card speed I was also unaware of, I assumed an SD card would be faster than an HDD, similar to how a SSD is supposed to be faster (even though they are not the same, the technology is similar). The hardfloat I was aware of, but I am not entirely aware of what kind of improvement it would offer. (You didn't mention this part, but I have seen it while floating around the internet in my free time) The answer that optimizing it to use hard float would improve performance with hard float related tasks isn't all that helpful, it just means I have to research into hard float and what it does, means, and potentially what I use that involves it as well as to what extentimage.

     

    Appreciate the options, but a lot of them don't make much sense to me, of course I could most definetly be wrongimage. I hope I don't sound like I'm bashing the Pi, I wasn't expecting a beast of a machine and I'm more than pleased with my $42-$43 (won't say $35, because I didn't pay $35) toy. But it's performance bugs me, because I know it can be better. I know it is somewhat new to being in the wild and will improve. I'm more curious than anything as to what it is that will improve it.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    >I've had hardware older than 2002 run better with lower specs than the Pi has, the year it was developed doesn't mean a whole lot to me, just because it is an old technology, doesn't automatically explain it's performance.

     

    older technology cpus have a lower instructions per cycle ratio.

    ARM chips are designed for low power, low transistor count,

    low cost, and synthesizable, rather than for high instructions/cycle. 

    The later ARMv7 cpus are faster and can issue more instructions in parallel.

     

    >8000 polls/second is still nothing compared to over 700 Million cycles/second,

     

    Dom measured the usb overhead at 20%.  The usb controller uses software

    to do work that normally is done in hardware, kind of like "winmodems" if

    you're familiar with those, so it is painfully slow.   Dom has tried to reduce

    the 8000 rate, but doing that caused other slowdowns, apparently due to

    dropped packets.

     

    http://www.element14.com/community/message/53203#53203/l/avoiding-usb

     

    >GPU not going to X I was not aware of,

     

    this is a big deal.  It's like running a PC without a graphics card.

    There is reportedly one volunteer working on it, but he's been on

    vacation the last month and doesn't have any firm schedule.

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=4649&start=100

    Codecs are also on GPU, but most are disabled for licensing

    cost reasons, such as MPEG-2.

     

    >SD card speed I was also unaware of, I assumed an SD card would be faster than an HDD,

    nope, huge benefit using USB HDD.  Initially, high-speed SD cards

    weren't supported at all.  Then with firmware upgrades this is improved,

    but low voltage and high speed modes apparently still lacking.

    SD drivers also seem to have spin locks with significant delays.

    Reducing the delays makes things faster, but some cards don't work.

    You should do some I/O tests with your SD card to see your throughput.

    Random I/O is particularly bad on SD cards, although sequential not as bad.

     

    There are some early I/O benchmark results here:

    http://www.element14.com/community/message/48386#48386/l/re-first-unboxing-pictures-maybe

     

    hardfloat:  I think javascript will be a big win, because all numbers are

    stored as floats. 

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    Okay, I see. So comparing an Arm cpu at a certain MHz rating to a more "common" cpu at the same speed is an inappropriate comparison except in the most general sense being that they are two very different things (I knew about the different instruction sets, but not the extent of the differences, merely the incapability between the two, which as far as I understand is why WINE will "never" work on the RPi).

     

    Never used a PC with a graphics card, always used onboard so that still doesn't mean much to me (like I always said, cheap, weak systems image). Although I am playing with a new powerful computer at work that will be the fileserver/webserver, first time I've ever used a computer that I deem to be above the just good 'nuff cut.

     

    So the USB loss is analogous to using ndiswrapper instead of a native driver (may be a bit of a stretch, but analogies help me understand better).

     

    Of course, I've come into contact with javascript (I am on the internet afterall, kind of hard to completely avoid unless you make a conscious effort to do just that), but I haven't necessarily "worked" with javascript (never coded in it) so I'm not familiar with the ins-and-outs of it. Are there any other applications that you are familiar with in which hard float is used? Of course, if not I always do have the internet and I don't really have any plans for the weekend except playing with my Pi and using the internet to learn more about it (all I know about Linux comes from personal experience and the internet, which has landed me two different university jobs [both offered to me personally, not applied to], so I do actively encourage people to "play" with their possessions, it helps you learn and can have unintended but awesome consequences).

     

    How would I perfrom I/O tests on my SD card, I am unaware of any standards and so far you seem very knowledgeable and helpful and we are already discussing these matters (otherwise I wouln't bother and would've searched for it myself).

     

    So if I were to put say, just the "MBR" (I use quotes because I believe it isn't really a MBR but just the first partition looked at when the device is on) as well as the /boot partition on an SD card, then the / (and any other partitions I would want to make and mount) onto an external HDD with its own power supply, I could expect a noticeable performance boost? That doesn't sound too hard and I can dedicate a small amount of my next paycheck to a cheap self powered external usb hdd to toy with (prices really have gone down in recent years). Also, maybe making a swap partition (with a low "swapiness" value or equivalent setting) I should in theory have some performance improvements (as far as I'm aware, of course) and perhaps less compiling errors due to running out of memory... This is an interesting prospect that I hadn't actually considered, seems like it would've been an obvious thing to do but quite frankly never struck me image.

     

    Thanks for the clarifications, always good to learn something new or to fix a false understanding image

     

    *EDIT*

     

    Also I looked at your forum post for the usb info. Interesting, I could always disable USB and use ssh for any intensive console work to improve performance during operations that wouldn't suffer much from being ssh'd like running an update or sending the command to compile. I wonder what kind of performance boost that could potentially offer (as opposed to any loss from ssh being used). Heck, then I could even run my Pi headless until I want to actually run something non-console based on it like a small game or something image

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    I added a link in my previous message to some I/O benchmarks.

     

    for the usb hdd, see:

     

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=10998

     

    btw, you say you use onboard graphics.  Imagine if your onboard

    graphics was disabled.  The GPU on RPi isn't used except to

    support OpenGL ES 2.0 and h.264 video, which isn't used except

    in quake3 and omxplayer.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    disabling usb also disables ethernet, so you have to use GPIO

    for the console uart.

     

    http://www.element14.com/community/thread/18844

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    Oh well, I'm sure there are other tricks to perform that could improve the performance than a clean little ssh move with no usb. I wonder how DirectFB would effect the usage of the Pi when it is finished.

     

    -Note-

     

    Network is unusually slow today, still download Raspbian+MATE to test on an 8Gb SD card. Maybe using my Roku 2 (I find it interesting they use the same SoC and I own both a Roku XS and a Roku 2 XD [esentially the $100 version of each at it's own time], I am learning all sorts of interesting stuff about my toys image) is killing my bandwidth!

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    btw, it actually makes sense to run the RPi headless, and use ssh

    from either a linux or windows pc (using XMing) where you run X.

    That makes X run fast because it doesn't depend on the RPi.

     

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=27&t=8772

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    Okay, I've only recently began using ssh (access work computers from home as well as sftp to move files between computers on the same network at a higher speed than copying over via a usb stick) and was unaware I could run X applications remotely. I was only aware that I could issue console commands and run console programs. Today just keeps becoming more and more progressive and has offered me some interesting ideas to play with in my mind as I wait to do more experimenting/playing. Don't use windows, haven't for a couple years and don't need to (you'd be amazed at how much the physics department of my university uses linux, especially when most of the other departments use windows).

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube