|
Is anyone else as tired as I am of every single web-site asking me to allow them to show notifications?
|
|
|
|
|
|
I've considered setting up a browser in a VM and saying yes to every notification/push request I get there. I wonder how long it would take for it to become totally unusable because of the notifications coming in.
How many people say yes to them? Must be enough to make it worthwhile.
Keep Calm and Carry On
|
|
|
|
|
k5054 wrote: How many people say yes to them?
I'm curious, what happens if you say yes? What's the mechanism?
Really I don't know what happens and too lazy to google a train load of TL;DR
pestilence [ pes-tl-uh ns ] noun
1. a deadly or virulent epidemic disease. especially bubonic plague.
2. something that is considered harmful, destructive, or evil.
Synonyms: pest, plague, CCP
|
|
|
|
|
yes
When you talk, you are only repeating what you already know.
But if you listen, you may learn something new.
--Dalai Lama
JaxCoder.com
|
|
|
|
|
Let me put you on notice: the rest of us have them disabled at the browser.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Also tired of ones that want to access your location.
|
|
|
|
|
That I have turned off at the OS level. I only allow the Weather tile and maps.google.com to access location. (If I didn't use google's navigator on my phone I'd disallow it as well.)
|
|
|
|
|
Greg Utas wrote: Also tired of ones that want to access your location.
Why? I often find it helpful. For example, you go to a store's website and if you allow location they can often already pre-select your local store. Not a big deal but a nice first-world luxury. 
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
I use a VPN, so the location is useless. Regardless, I'd rather enter a postal code to select a store. My location is none of their business, particularly when so many of these sites share information with whoever wants it.
|
|
|
|
|
Greg Utas wrote: these sites share information with whoever wants it.
What's the harm in that? They share your IP and zip code with someone. So?
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
My IP is that of a VPN, so it's useless. My mailing address is a UPS store.
I guess it's a just a matter of how much one cares about privacy.
|
|
|
|
|
Greg Utas wrote: My IP is that of a VPN, so it's useless. My mailing address is a UPS store.
So, even more so, who cares?
Greg Utas wrote: I guess it's a just a matter of how much one cares about privacy.
That's fair. But to convince me there needs to be some logic behind it, not just emotions.
Are you old enough to remember the white pages? Did you call up and remove yourself?
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Ask the Founders why they wrote it into your Constitution.
And you're trolling me.  
|
|
|
|
|
Greg Utas wrote: they wrote it into your Constitution.
Privacy? But you even admitted that they can't get your data anyway.  
I notice you dodged the question about the white pages.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
There was a time I was in the white pages, but I matured. 
My mobile is still Californian even though I last lived there 15 years ago.
|
|
|
|
|
Greg Utas wrote: There was a time I was in the white pages, but I matured.
So, this is what I find fascinating. I don't recall anyone ever complaining about a huge book of names, addresses, and phone numbers being handed out for free.
Now with the internet, people are scared over data that can't even be linked to them being shared with someone.
It's not a knock on you and no I am not trolling. I am genuinely amazed at how that has shifted and am very curious as to why. No one seems to know what dangers there might be with linking an ip address with a zip code yet so many people, especially technologically educated people, are so worried about it. I don't understand it which is maybe why it fascinates me.
Greg Utas wrote: My mobile is still Californian even though I last lived there 15 years ago
That explains why you don't answer when I call. 
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
I think what has changed is stuff like identity theft, hacking, surveillance, and stalking.
The only identity theft I heard about back in the day was people who wanted to disappear. They'd steal the identity of someone who died in childhood, get a birth certificate, apply for a social security number, and establish a completely new identity.
|
|
|
|
|
Remember the good old 8086 and how it used its segment registers? Essentially I'm doing something like that on an 8 bit computer right now and can then address up to 16 megabytes. Unfortunately my segment registers will not be part of the CPU, so there will be no automatic address calculations during interrupts, DMA, subroutine calling or even normal branching. The computer is still confined too much in its regular 64k address space.
That's why I have no choice than to slice up this address space into smaller segments which can be switched individually. With a little care the segments then can be switched around without an instant crash.
The big question now is what sorts of segments are most practical and how big they should be. Let's look at the 8086 segment registers for inspiration.
The stack segment: As I said, the stack should not be switched away. Let's also throw in interrupt routines and DMA buffers. Would that not be a waste of expanded memory if only one page in this segment is used? No. Every process would get its own page and (when interrupts and DMA are disabled) the OS can map in I/O ports, video memory or keep track of its processes and memory management.
The code segment: I can emulate a full MMU in software when calling subroutines. That means I can call code in any page of the code segment at any time without problems. The code in every page would have the character of a module, a DLL if you want. I could call the subroutines by an ordinal instead of addresses, add memory management on the code segment and (with a proper storage device) even implement virtual memory, just in time loading of these modules or even just in time compilation. Quite advanced for a little 8 bit computer.
The data segment: Very nice to have, but only at a cost. Pros: Your programs get access to much more memory than they would without it. Also, this segment is a good alternative to access I/O and video memory if you can't do that on the stack segment for some reason. Con: The code segment gets smaller.
This is my current mix:
0000 - 7FFF code segment (32k)
8000 - BFFF data segment (16k)
C000 - FFFF stack segment (16k)
Any better ideas which might work better? Have I forgotten something? If i make a bad decision now, I will have to live with it for a long time.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I'd throw in one (or more likely two) more: system code / system data - this holds the interrupt handlers, system stack and "bios" code that you need to handle the MUU - doesn't have to be a big segment (depending on your coding abilities / compiler if used) but having always available and always in the same place is a big bonus.
If I recall correctly (and I last used an MMU twenty years ago) that's how I had my memory organised in the Z180 / HD64180 MMU, and it allows for flexibility and speed in response to "system events".
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I have thought about doing something like that, but decided against it. This way the other segments get bigger and also a larger share of the expanded memory. I would put only the master interrupt routine into the stack segment. This interrupt routine would then call separate innterrupt routines in some module loaded into the code segment. There would be some register saving and bank switching involved, but it should work.
The same goes for normal OS calls. The processor calls and returns from subroutines with the help of small procedures that do the proper bookkeeping on the stack. Or stacks, in my case. I use a separate call and parameter stack. By saving the content of the code segment and the data segment registers in the call procedure and restoring them in the return procedure I can call code anywhere and continue where I left off upon returning. These two small procedures also have to go to the stack segment.
Did you ever use FORTH? It works in a similar way, organizing the code into a dictionary with 'pages' and 'words'. The pages are all about memory management and I really see no problem adapting it to a paged memory model. That's also why FORTH is an interpreter or a (just in time) compiler at the same time, just as it is operating system and programing language at the same time. Just implement more words and add pages to the dictionary, then let the memory managment worry about where and when to load them. FORTH always was a hype waiting to happen, but I can see why it is too exotic to ever become mainstream.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
similar to OG I was wondering where are you putting your kernal (hypervisor?), page tables/states.
... you mentioned the stack segment may be underused, would the above go there. (I/O ports too?)
... even then the state settings/info you may find 16M becoming optimistic, 8M may be doable.
pestilence [ pes-tl-uh ns ] noun
1. a deadly or virulent epidemic disease. especially bubonic plague.
2. something that is considered harmful, destructive, or evil.
Synonyms: pest, plague, CCP
|
|
|
|
|
Look at my reply to OG. FORTH has always handled these things quite well. On tiny microcontrollers, single board computers and even modern systems. You can even use assembly subroutines or compiled C functions if you don't forget to tell FORTH that it should better not try to interpret or compile these new 'words'.
But don't worry, I get most of my 16 megabytes. On the hardware side I always have my 24 address lines. I will sacrifice 512k of that space by not installing the last memory chip and use it's select signal as master select for the memory mapped I/O ports and video memory. With a little addressing trick (actually just ignoring A15 and A14) I can even select these things into any segment if the stack segment is not convenient.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
What kind of software are you going to run on this "beast" ?
How much control do you have over the software?
My experience with that small systems is that stacks are surprisingly shallow.
If my memory is correct, the 8051 stack is 256 bytes. With that tight limits, you soon learn to pass multiple arguments as a pointer to a struct with the inidividual values, and to structure your code to "get out of there" as quickly as possible. Avoid nested calls whenever you can do them as a sequence. Maybe each operation nests 2-3 levels deep, but not dozens of levels. You should strive to keep the stack shallow: E.g. initialization functions should return before starting the "real" appliction code. Even if plan to run code that you cannot control, 16Ki is a lot.
Are you using languages requiring a static link? Or languages allowing pointers to locations in the calling routine (e.g. in frames deeper down on the stack)? If not, you could virtualize the stack segment as well, keeping only the topmost frame directly adressable. Then all function calls must go through a (redsident) stub that unmaps the current frame and sets up the new, and upon return remaps the caller's frame (as well as mapping in the code segment with the current function, if it is not the current one).
Years ago, I worked on a banked 8501: The upper 16K could be switched between four banks (but I believe that the architecture allowed extension to an arbitrary number). Banks were not pure data or code, they could have both. Each bank typically contained one module or functional subset: When you loaded a bank, you would usually stay in there for a major piece of work, with direct, "normal" calls within the bank. Libraries used by "everyone" was located in the common, lower 48K and could also be called directly; only when a function in one bank needed to call a function in another bank went via a stub (in the lower 48Ki).
Globally static data, shared among banks, were located in the lower 48Ki; data relevant only to the functions in one bank was located in that bank. Care was required: You could not pass a pointer to data in a bank to a function in another bank. For such needs, the data had to be allocated in the common 48K.
If I were to design a new banked system, I guess I would stick to the same solution: A bank can have both code and data. I would probably increase the bank size to 32Ki; that would make larger functionality in a single bank, reducing bank interactions, fewer bank switches. Most likely, a fair share of banks would not be filled up. For really large systems, filling up physical RAM, it would be nice if a half-filled bank, 16Ki, would require only 16Ki in backing RAM. Allocating bank space in e.g. 1Ki increments would allow a larger number of banks.
The lower half would hold interrupt handlers, DMA buffers, data shared between banks, stubs for all exported banked functions (e.g callable from arbitrary bank), and buffers where one bank can place argument structs when calling functions in other banks. The stack would be in the lower 32Ki. If your stack grows downwards (which is quite commmon) and you have Stack Limit register, why don't you fill the common 32Ki from the botton, ending with setting Stack Limit to the current load address, and the stack bottom to 32Ki - then you can increase stack space avialable when needed by moving more of the common code/data into yet another bank. For a stack growing upwards, you could of course let it grow from the end of common code/data, up to 32Ki, but there is a tradition for starting the stack at a "round" address.
The old open-source P4 Pascal compiler shared all unallocated adress space between the stack and the heap, growing from each end. If a heap allocation could not find a free area below the current HeapTop, HeapTop was pushed upwards for the request, and compared to the current StackTop, for an out-of-space check. Similarly, a function call would check tbe new StackTop against HeapTop, and report a collision if space was exhausted. So a program with deeply nested calls could not use as much heap space, and a program using the heap a lot would have to refrain from too deeply nested calls.
I guess I would not try to virtualize (bank) the stack; that would require dynamic allocation of banks.
Another factor: This CPU, does it provide any harware signal indicating whether it is fetching instructions (code), accessing data, whether the stack register is involved in the address calculation or if you are in an interrupt handler? Many CPUs do, and you might use these signals as bank selectors. The 16 bit address could effectively be extended to 18 bits: One 64Ki code space, one 64Ki data space, one 64Ki stack space, and one 64Ki interrupt space. (So it would switch the lower 32Ki as well). Where DMA fits it would depend on the how the signals are set during DMA. Each of these four spaces might be banked. (I guess that stack and DMA would have only a single bank, but if it treated as such, the banker should be able to map the DMA bank with data buffers as a data bank accessible to "ordinary" (non-DMA/interrupt) code.
All of this of course depends on the available signals from the CPU, as well as the flexibility of your bank mapping mechanism (e.g. if an interrupt can immediately swith to the interrupt bank, sufficiently fast for the interrupt handler), or if the DMA can be hardwired to one specific lower 32Ki independent of the mapping of code, data and stack. If the hardware is alredy designed and implemented, I guess it is difficult to accomodate new proposals at this level.
|
|
|
|
|
Ah the 8051/8052. I have really done incredible stuff with it. It is amazing what you can squeeze out of 256 bytes of RAM. In combination with 32 kbyte of EPROM what you can do is truly amazing. Full blown control systems for nearly every type of compressor, it was absolutely fantastic.
Later I used versions from silicon labs which performed up to 100 Mips with 64 kbyte of flash memory with a few kilobytes of external Ram, they were perfect to implement all sorts of communication gateways.
Those really were the days.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
