XPost: alt.computer.workshop   
   From: BD@hotmail.co.uk   
      
   On 12/08/2025 14:23, David B. wrote:   
   > On 29/06/2016 00:53, Diesel (Dustin Cook!) wrote:-   
   >   
   >> "p-0''0-h the cat (coder)"    
   >> news:qkf3nb1upourvsqoi70t2cilce5a93fkpa@4ax.com Tue, 28 Jun 2016   
   >> 00:21:22 GMT in alt.comp.freeware, wrote:   
   >>   
   >> I just did a quick read on your z80 spectrum system. It has quite a   
   >> history. Comparable to that of a Commodore 64, although the Commodore's   
   >> technology was better. Various other systems I played with, Amiga,   
   >> Atari, Coco3, were superior to it. Popular in your country, though. Not   
   >> so much here...   
   >>   
   >>> Let it go Dusty. I've written much bigger programs in assembler   
   >>> than you have, without using other peoples code   
   >>   
   >> As I said, if you'd been honest, I wouldn't have prodded you the first   
   >> time. You were talking shit and I busted you. If you didn't make use of   
   >> any pre existing routines available to you via your OS and/or hardware   
   >> ROMS, that was your choice...   
   >>   
   >> As for me, If the Interrupt and/or API does exactly what I want without   
   >> being slow and/or wasting memory, I'll use it. Otherwise, I'll just do   
   >> it myself. The only time you don't use them is if your way is   
   >> faster/more efficient or they can't do exactly what it is you're   
   >> wanting to do. Otherwise, you'd be a fool not to take advantage of   
   >> what's available.   
   >>   
   >> I can call an api to play a wav, or, I can load the wav, , process its   
   >> header myself, manually access the soundcard and enter a ready   
   >> state/send more data loop, while controlling the playback speed myself.   
   >> OR.. Option 2, pass the filename off to an API call and let it deal   
   >> with all those wonderful details, freeing me up to do more important   
   >> shit. I can do the same with a jpg, tiff, etc. Process it entirely   
   >> myself, or, call an API to do the work.   
   >>   
   >> Did you write the assembler program yourself? Did you write the   
   >> firmware present on your speccy that allowed you to use an assembling   
   >> program? As, your spectrum boots up like the machines I cut my teeth   
   >> on. They loaded BASIC from ROM and left you sitting at a flashing   
   >> cursor. So.. you needed additional software to pull this off. Did you   
   >> write it yourself, from scratch? using pure machine code? If not, you   
   >> used somebody elses code, then... didn't ya.   
   >>   
   >>> I know more about embedded systems   
   >>   
   >> Depends on the systems... you seem to be ambiguous, I suspect   
   >> intentionally.   
   >>   
   >>> air interfaces   
   >>   
   >> Depends...   
   >>   
   >>> unices   
   >>   
   >>  From a desktop POV, mebbe.   
   >>   
   >> Your attempted trolling with 'it's not pure code because you called an   
   >> interrupt' is not only assinine, it seems to fly in the face of the   
   >> Unix Philosophy, too...That you've proclaimed far more knowledge of   
   >> than myself. Which I find especially odd, as the principles describing   
   >> coding practice are indeed, the principles I've followed since I   
   >> started writing code, when I was a kiddo. I always thought, smaller,   
   >> easier to read code that did one thing and did it well was better than   
   >> some larger program that tries to do several different things.   
   >>   
   >> Every program I've released has followed a design principle that   
   >> predates the very OSes I wrote the programs for. LARF!   
   >>   
   >> https://en.wikipedia.org/wiki/Unix_philosophy   
   >>   
   >>> system engineering   
   >>   
   >> So, the reason a Bestec or rebranded Delta Dell is better than a   
   >> Seasonic, Corsair, etc, PS is? It's sound system engineering to put in   
   >> a weak PS that cannot hold out at the full wattage load rated on it's   
   >> name plate?   
   >>   
   >> Tell me again why in the states, We cannot purchase off the shelf   
   >> components, assemble them, load an OS, and resell it.   
   >> ,   
   >>> networking   
   >>   
   >> LOL. I'll just agree to disagree with you on this.   
   >>   
   >>> mail servers   
   >>   
   >> Sorry, but, I've gained unauthorized access to one to many to take your   
   >> claim seriously.   
   >>   
   >>> you name it   
   >>   
   >> Oh? How about writing code intended for x86/64 processor families?   
   >>   
   >>> I know the difference between CVS and CSV   
   >>   
   >> I thought! it was a typo. I was giving YOU the benefit of the doubt.   
   >>   
   >> Btw, tell me again how source code alone is useless?   
   >>   
   >>> how to hide services from nmap   
   >>   
   >> You have an MID or two showing that I do not? If so, I'd like to see   
   >> it/them.   
   >>   
   >>> the difference between a switch and a hub   
   >>   
   >> As do I. I still enjoy using a hub to sniff packet data, though. It's   
   >> quicker than reconfiguring a switch to do it.   
   >>   
   >>> I  know what a rootkit contains .   
   >>   
   >> LOL! So do I. Unlike you though, I've made the distinction between the   
   >> Windows concept of a Rootkit and the Unix varient.   
   >>   
   >> Let's see how close I was:   
   >>   
   >> https://en.wikipedia.org/wiki/Rootkit   
   >>   
   >> A rootkit is a collection of computer software, typically malicious,   
   >> designed to enable access to a computer or areas of its software that   
   >> would not otherwise be allowed (for example, to an unauthorized user)   
   >> while at the same time masking its existence or the existence of other   
   >> software.[1] The term rootkit is a concatenation of "root" (the   
   >> traditional name of the privileged account on Unix-like operating   
   >> systems) and the word "kit" (which refers to the software components   
   >> that implement the tool). The term "rootkit" has negative connotations   
   >> through its association with malware.[1]   
   >>   
   >> Rootkit installation can be automated, or an attacker can install it   
   >> once they've obtained root or Administrator access. Obtaining this   
   >> access is a result of direct attack on a system (i.e.), exploiting a   
   >> known vulnerability (such as privilege escalation) or a password   
   >> (obtained by cracking or social engineering). Once installed, it   
   >> becomes possible to hide the intrusion as well as to maintain   
   >> privileged access. The key is the root or administrator access. Full   
   >> control over a system means that existing software can be modified,   
   >> including software that might otherwise be used to detect or circumvent   
   >> it.   
   >>   
   >> Rootkit detection is difficult because a rootkit may be able to subvert   
   >> the software that is intended to find it. Detection methods include   
   >> using an alternative and trusted operating system, behavioral-based   
   >> methods, signature scanning, difference scanning, and memory dump   
   >> analysis. Removal can be complicated or practically impossible,   
   >> especially in cases where the rootkit resides in the kernel;   
   >> reinstallation of the operating system may be the only available   
   >> solution to the problem.[2] When dealing with firmware rootkits,   
   >> removal may require hardware replacement, or specialized equipment.   
   >>   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)